Heap fragmentation (Was: Debugging "Leaks" With Boehm-GC)

Sun Jan 15 00:46:00 GMT 2006

Hi Daney,
>>>> 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.
>>>>>> 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.
>>>> Just stumpled across this old thread - seems that I'm beginning to run 
>> into fragmentation problems - bot being able to allocate memory for 
>> some things.
>> I have set GC_MAXIMUM_HEAP_SIZE to 14000000 (14mb), but I wonder where 
>> I can configure GC_free_space_divisor? In "alloc.c" it seems - but 
>> there it's set to 3, whereas "gc.h" says it's initially 4?!
>>> We set GC_free_space_divisor before calling JvRunMain. I don't know 
> what happens if you call it after the runtime is already started.
But where is it configured? I will look for it in the morrow - if it's a 
matter of searching for "GC_set_free_space_divisor" in the libjava 
folder, I'm on it ;-)
>> Moreover, is 20 a super value? Or is this trial-and-error?
 >
> Trial and error.
Bummer :-)
> The larger the divisor, the more time spent in GC, but the less likely 
> you are to end up in the pathological situation where there is plenty of 
> free memory, but it is all in pools for objects of a size other than you 
> are trying to allocate.
Exactly - I have plenty of mem free (>5 megs out of 14), but no way to 
use it :-)
> I think the default value is probably appropiate for cases where there 
> is no upper bound on memory size. For bounded memory size, we have 
> found that a larger divisor is needed.
I'm just glad the posibility it's there
// Martin