On Sun, 2009-02-01 at 13:44 +0100, gustav trede wrote:
Hi Gustav,
great that you are looking also at Slab Memory Management.((-:
I think Alexey and me could really use some help ((-:
> Hello,
>
> SlabPoolImpl , all public methods share the same lock.
> All memory allocation are performed inside the synchronized
> context...
>
> I would be happy to fix the implementation , but would like to get
> answers to these question first:
>
> If there is a need of truly exact size limits ? ,if so all set size
> changing operations will be forced to be synchronized, no need for
> concurrenthashmap.
>
> Is there a real need to have the functionality to close ?, should that
> not be handled in a more natural indirect way ?
I am not sure if changing synchronized signature will provide any
benefits.
A SlabPoolImpl is just memory divided into big peaces of
Slabs. Each Thread has its own MemoryManager(SlabPoolMemoryManagerImpl)
which then uses its own Slab to allocate Buffers. So if the size of the
Slab is chosen well MemoryMangers should not very often need to contend
for new Slabs
In the moment I am hoping that allocation since each WorkerThread has
its own
MemoryManager will not have many concurrency issues. The difficulties
will come when StreamReader which is used to access the "read in" bytes
is accessed from another Thread
Many Greetings
John
P.S: I just realized that each MemoryManager has its own SlabPoolImpl.
this was just a typo and I'll fix it.
>
>
> --
> regards
> gustav trede
>
>