John,you managed to write quite a lot text, without answering any of my
questions.
baby talk like ((-: is something you can keep for yourself please,
especially when your using it to negate positive worlds in the same
sentence.
2009/2/1 john <snake-john_at_gmx.de>
> 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
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>
--
regards
gustav trede