Oleksiy Stashok wrote:
> 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).
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.
SlabMemoryManager relies on the further processing by StreamReader to be
given back the used memory (Bytebuffer)
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.
What do you think?
How was your holiday?
Many Greetings
John