Gustav,
> 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.
SlabPoolImpl does not have a concurrenthashmap and no set size operations.
Which class are you referring to?
> > >
> > > 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
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01