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

Sun Jan 15 19:48:00 GMT 2006

Hi Hans,
>>>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.
> That should be OK. It should control future GC/heap expansion decisions.
Good to know!
>>>Moreover, is 20 a super value? Or is this trial-and-error?
>>Trial and error.
>>>>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.
>>>>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.
> If the issue here is really fragentation, it would be nice to understand it
> better. A call to GC_dump() or setting the GC_DUMP_REGULARLY environment
> variable should tell you what's in the heap. 

No, do you recall:
http://gcc.gnu.org/ml/java/2005-12/msg00083.html
setting GC_DUMP_REGULARLY doesn't affect anything - what should happen?
 > Really fragmentation per
> se can only occur if either:
>> 1) The application drastically changes the object size mix it needs for
> different phases, and some other things go wrong. And even then, things
> shouldn't get too bad. Or
>> 2) The problem occurs due to frequent allocation of large objects.
By "large" I guess mean some that takes "relatively" much of the free 
memory?
I'm doing many ~20kb - and suddenly a ~200-400kb
> On the other hand, there is a known problem with large root sizes causing
> the collector to grow the heap to better amortize the GC overhead.

// Martin