Re: Debugging "Leaks" With Boehm-GC

[David Daney <ddaney at avtrex dot com>]

Craig A. Vanderborgh wrote:
> Hello Everyone:
>
> We are currently experiencing some dire difficulties with one of GCJ's 
> most opaque aspects - garbage collection.
>
> The application exhibiting "leaks" is an XML browser of our own 
> creation.  The use case that "leaks" is one where our browser software 
> works its way through interpreting some page elements, and then throws 
> an "event", which is implemented by throwing a Java exception, which 
> something up the stack elements then catches.  The software works 
> beautifully, except it "leaks".

The boehm GC in certain circumstances suffers from memory fragmentation. 
 When this happens, even though there may be 'free' memory, it cannot 
be used so the GC must try to obtain more memory from the OS.

We have seen the exact behavior you are talking about.  An application 
that can run for days in Sun's jvm showing no leaks with Borland's 
memory debugging program (I forget its exact name).  But when run under 
libgcj it quickly runs out of memory.

The solution we found was to increase the GC_free_space_divisor (to a 
value of 20).  Using this in conjunction with calling 
_Jv_SetMaximumHeapSize() to set the maximum heap size gives us very good 
results (A fixed heap size that never fills up).  There is a trade off 
in increasing the GC_free_space_divisor, in that it increases the 
frequency of GC events with results in reduced performance.

With an unlimited heap, the default GC_free_space_divisor gives good 
results, but with a heap limited to a small value it is known to cause 
allocation failures even though there is enough free memory to satisfy 
the request.  The reason has to do with the way the the GC groups 
allocations of same sized objects in to dedicated blocks of memory

David Daney