Hi John,
>>
>>> 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?
> there is no problem. you can do that right now.
> it was only meant as a first usage case
Ok, that's good.
>>> 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.
> Well if we are brave we should do this as soon as possible ((-:
Agree. Once you'll say it's ready :)
>>
>> 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...
> right! It wasn't clear to me that you intended to go so far ((-:
> yes you would have a list with "ready to be parsed buffers" stored
> in the connection.
>
> When using Slab-Memory-Management you have the choice of 2 different
> implementations :
> SlabMemoryManagerImpl using garbage collection or
> SlabPoolMemoryManagerImpl using a pool.
>
>
> SlabMemoryManagerImpl is in some respect similar to
> ByteBufferViewManager which is the
> current default MemoryManager. This switch might lead to the
> creation of more
> ByteBuffers instances (these instances are only slices) since we
> cannot reuse a ByteBuffer-slice stored in WorkerThread anymore.
> So we might loose some memory effiency here?
May be it's not critical. We will check this using perf. tests.
> But then if memory effiency is important you could use
> SlabPoolMemoryManagerImpl.
> The drawback here is that users have to make sure that space is
> allways given back to the pool by
> calling ByteBufferWrapper.dispose(). Otherwise you really get in
> trouble ((-:
First of all we can try to hide Buffers as much as possible. We will
have streams, right? :)
On other hand it could be good to avoid having troubles, if Buffer is
not getting released. Can we just forget it and let GC process it?
Thank you.
WBR,
Alexey.
>>> How was your holiday?
>> Oh, as usual. Nice and short :))
>> What about you?
> also very nice ((-: And the good news is that in 10 days I have
> another holiday haha ((-.
>
> Many Greetings
> John
>
> --
> Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL
> für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>