[Gc] Re: Heap size and stop-the-world collections

Boehm, Hans hans.boehm at hp.com
Wed Jul 12 11:18:20 PDT 2006

I think a lot of the characteristics you are observing here are common to all tracing collectors.

I don't fully understand the description of your test program.  The GC does report that about 1MB of new objects are allocated between collections, suggesting that it is really mostly an allocate/drop loop with little live data?

Assuming this is true, generational collection doesn't help for such an application.  If anything much ends up in the old generation, that's a mistake.  In this case, a full GC is nearly equivalent to a minor GC.

Since you continue to allocate and drop objects, you will presumably continue to need to collect.  The collections may happen earlier in your toy example than you want them to.  You can force the collector to use the entire heap (GC_use_entire_heap, probably not recently tested).  This is probably a win if you are allocating only small objects, but often causes fragmentation problems for real apps.  A compacting collector would avoid this issue.  (The default setting effectively reduces the footprint of your app and avoids fragmentation, at the expense of GC time.)

GC_ENABLE_INCREMENTAL definitely wont help in this case.  In other cases, it rarely improves throughput.  The algorithm could be improved, but there are also some inherent limitations caused by the granularity at which we track dirty objects (pages, which are too large).  This is really only a useful option to reduce pause times in large heaps.

You can tune the heap expansion heuristic.  Look for GC_free_space_divisor.  This mechanism doesn't work terribly well if you want huge sparse heaps.  In GC7, that's easily fixable, but I haven't sensed a large demand for it.

The GC times are probability a bit larger than with a non-conservative collector, since by default a lot of static data is included in the root set.  Even minor collections generally rescan that, since it's often hard to track modifications outside the heap.  There are hooks in the collector to tell it where the relevant roots actually are, if you want to go through the trouble.  Gcj is starting to be much more careful about this.


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ludovic Courtès
> Sent: Wednesday, July 12, 2006 5:36 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Re: Heap size and stop-the-world collections
> Hi,
> Lothar Scholz <scholz at scriptolutions.com>
> writes:
> > The reason is that the gc is not a generational collector. 
> It's a very 
> > simple stop-mark-sweep implementation.
> According to [0]:
>   The collector uses a mark-sweep algorithm. It provides 
> incremental and
>   generational collection under operating systems which provide the
>   right kind of virtual memory support. (Currently this includes
>   SunOS[45], IRIX, OSF/1, Linux, and Windows, with varying
>   restrictions.)
> So, since I'm using GNU/Linux (PPC), setting 
> `GC_ENABLE_INCREMENTAL', intuitively, should yield a nice 
> improvement for my use case.
> Thanks,
> Ludovic.
> [0] https://www.hpl.hp.com/personal/Hans_Boehm/gc/
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list