[Gc] Re: Are there any tuning options for thread local allocator?

Boehm, Hans hans.boehm at hp.com
Mon Oct 4 21:01:51 PDT 2010


The allocation is still the bottleneck?  What sizes of objects are being allocated?

It should normally be allocating on the order of HBLKSIZE bytes per lock acquisition.  But it only does so for objects up to about 256 bytes.  And only after the allocating thread has warmed up and allocated a bunch of objects of that size.

It may work to increase HBLKSIZE.  That probably has a better chance of working if MPROTECT_VDB does not get defined.

If the problem is really in the marker, you may want to make sure that PARALLEL_MARK is also turned on.

Hans

> -----Original Message-----
> From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
> On Behalf Of Paul Bone
> Sent: Sunday, October 03, 2010 11:56 PM
> To: gc at linux.hpl.hp.com
> Subject: [Gc] Re: Are there any tuning options for thread local
> allocator?
> 
> Lothar Scholz <scholz at scriptolutions.com> wrote:
> > Hello,
> >
> > I found that the malloc is still the serious bottleneck in my program
> > when i go from 2 to 4 cores. I have the thread local allocation
> > enabled but it seems that it keeps to few memory chunks local and so
> > it has access the global mutex often.
> >
> 
> I would also like to know this.  Specifically I have a program that
> allocates many small cells.  I want to tell Boehm to cache more small
> cells in it's thread-local pool so that it does global allocation less
> often.  Perhaps each thread should take more memory from the global
> pools each time it has the lock.
> 
> 
> --
> Paul Bone
> Computer Science Research Student.
> http://www.csse.unimelb.edu.au/~pbone/
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/



More information about the Gc mailing list