Hi John,
>>
>> Hi John,
>>
>> I had some time today to take a look at Slabs memory management
>> code in Grizzly 2.0. IMHO it looks very good, thank you!
>> Have one idea about SlabMemoryFilter... IMHO we can avoid to use
>> such a filter, but correct me if I'm wrong. The idea is to move the
>> logic from this Filter to SlabMemoryManager(Base). So, when you'll
>> call SlabMemoryManager.allocate(...) - it will check current thread
>> and associated slab allocator. So we can avoid of using additional
>> Filter.
>> What do you think?
> Hmm I am not too sure.
>
> I 'm ok with the allocate(..) proposal.
> I would create a ThreadAttachedMemoryManger which delegates to
> SlabMemoryManager.allocate(...)
> because I would like to keep the dependency on WorkerThread out of
> SlabMemoryManager (nicer for testing).
Ok, +1.
> Unfortunately SlabMemoryFilter main purpose is to efficiently read
> in bytes .
> 1) Therefore it allocates a very big ByteBuffer.
> 2) Invokes connection.read()
> 3) It then trims the very big ByteBuffer which actually gives
> SlabMemoryManager the unused space back.
> 4) It sets the "filled in ByteBuffer" as the contexts's message.
>
But it is possible to do in general way, not just with slabs, right?
(We have trim() method declared in common Buffer interface).
> SlabMemoryManager relies on the further processing by StreamReader
> to be given back the used memory (Bytebuffer)
Is it possible to avoid such a dependancy, so SlabMemoryManager could
be used in all usecases, not just Streams?
> This is different to Grizzly's 2.0 default memory processing which
> is done in TCPNIOTransportFilter.
> For example there is no ByteBuffer associated with each Thread nor
> is there any storing of ByteBuffer in the connection.
Ok, we can remove ByteBuffer<->Thread association once
SlabMemoryManager will become default memory manager.
As for storing ByteBuffer in a connection. Think there is not such a
usecase for Slabs, because you mentioned it works just with Streams,
right?
But what if we will want to make it general default memory manager for
Grizzly? In this case, IMHO, we may need to store some Buffers in a
connections, because of incomplete parsing or so...
> How was your holiday?
Oh, as usual. Nice and short :))
What about you?
Thanks.
WBR,
Alexey.
>
> Many Greetings
> John
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>