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

Tue Jan 17 22:07: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.
>>>>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. Really fragmentation per
> se can only occur if either:

Here goes Hans - attached is a dump from GC when it crashes followed by 
a GC-dump after the client gave up it's attempt to do the "RPC-operation".
I can provide you plenty of dumps :-)
Regards,
 Martin Egholm
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dump1.txt
URL: <http://gcc.gnu.org/pipermail/java/attachments/20060117/4c4371cc/attachment.txt>