RE: GC leaks debugging

["Boehm, Hans" <hans dot boehm at hp dot com>]

Finally getting around to looking at this thread:

It still looks to me like the 32-bit version had serious blacklisting issues, possibly in addition to other problems.  It looks to me like the root sets it's tracing are too large, and they contain too much essentially random data that ends up looking like pointers.  That may not be the only, or even dominant, problem.

But let's continue with the 64-bit version that doesn't share the problem, and should be fine.

What does the GC log look like for the C++ test program you posted?  How much live data is the GC finding?  That test program is pushing the envelope in a couple of different ways:

1. It potentially causes lots of fragmentation if some of those objects are not immediately reclaimed.  This garbage collector doesn't like large objects very much.  I would expect that even some copying collectors would run into trouble with this, in that copying such large objects is expensive, and they may try to avoid compacting them.  Others would probably do OK.

2. The heap expansion heuristic in the GC versions < 7 is not very robust in cases like this.  It tries to allocate a fixed fraction of the heap between collections, and grows the heap if that fails.  With large fragmentation, it may never succeed.  Version 7+ fixes this by trying to allocate a fixed fraction of live data, not the overall heap size.  That involves tracking live data, at least approximately.  Setting a hard limit on the heap size (GC_MAXIMUM_HEAP_SIZE environment variable) might be a workaround.

> From: Andrew Haley [mailto:aph@redhat.com]
> 
> > Just two questions:
> > 1. What is a reasonable number of heap sections?  I have 131 here.
> > 2. What is a reasonable number of free lists?  I have 60, which have
> > 13,000+ entries.
> 
> Paging Hans Boehm.  can you suggest ways to get the system to GC more
> frequently?  Would doing so avoid this scenario?
> 
> Andrew.
There is a static, configuration-dependent limit on the number of heap sections.  So long as you're not running out, I wouldn't worry about it.

What kind of free lists are we talking about?  If these are the large block lists printed by GC_dump(), then 13000+ entries sounds really high.  If so, could you post an appropriate excerpt of what's in these free lists?  For small object free lists, that's probably OK.

Hans