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

Tue Jan 17 16:37:00 GMT 2006

>>> 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

>>For my this was the problem.
>>>>For certain definitions of 'drastically' and for heaps of certain size
>>limits using the default divisor: "shouldn't get too bad" is equivilent
>>to "out of memory".
>>>>Now I don't know if you would call it classical memory fragmentation,
>>but what ends up happening is that the memory pools for small sized
>>objects grow to such a point that allocation of objects of a newly seen
>>size fails. There is plenty of space for objects for which there is a
>>large pool.
>> I think for this to fail as described, you need not only need to allocate
> lots of small objects as you describe, but then also drop most of them,
> but leave at least one live in each heap chunk/block. Otherwise the entire
> block would be reclaimed, and it should be usable for large objects again.
>> That's certainly possible. It's just not something I've seen a lot of.
> But it does explain why the problem gets much better with a larger
> GC_free_space_divisor, which was a bit of a mystery to me before.

I've tried setting it to both 6, 10, 20, and 40 (and default [3,4]?)... 
It looks like a value of 10 is somewhat good for me... Although it 
increases GC frequency - as expected but not so good for me ;-(
And then an extra question:
I notice that the "Complete collection"-time increases quite when I 
suddenly "activate" (addresses and use the classes) new parts of my 
application (as expected I guess). But when finished using that part and 
all instances "should" be GC'ed, the GC-time remains the same (high) value.
Is it because I actually do have leftover-instances, or is it just the 
nature of the GC - "once seen, always being 'scanned'"?
It would be nice to be able to "unload" that part of the application 
again, winning costly GC time...
// Martin