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

Fri Jan 20 11:53:00 GMT 2006

> From: Martin Egholm Nielsen
> > You might check the finalizable object statistics, and make 
> sure that 
> > number is not continuously growing over time. It seems 
> fairly high to 
> > me, but I don't have good gcj statistics to compare it to.
> Ehm :-) Where do I find this "finalizable object statistics"?
The GC_dump() output concludes with a "Finalization statistics" section.
The "finalization table entries" number looks slightly suspicious. Note
that inflated locks have to be finalized when the underlying object
disappears, so the runtime will contribute some entries here. (I'm not
sure that relying on the finalization interface here was the right
decision, but it is the current decision.)
>> ...
> I guess I'll aim for the increased divisor, plus a reduction 
> in the big 
> allocations sizes - that's a parameter I can change - however, not 
> without breaking my high level client-server protocol ;-]

Since it sounds like you're allocating these objects repeatedly, and
they apparently don't contain references, any chance you can allocate
just one and reuse it? (If they did contain references, you'd have to
make sure that those get cleared in between.)
Repeatedly allocating and dropping a 450K+ object isn't going to help
the performance of any garbage collector. 
Hans