Re: GC leaks debugging

[Andrew Haley <aph@redhat.com>]

On 01/04/11 09:39, Erik Groeneveld wrote:
> L.S.,
> 
> I am debugging memory leaks in the GC of libgcj.  Generally, libgcj
> performs well, but there are some cases in which the heap literally
> explodes over time. I wish to solve this. The OpenJDK vm runs the same
> tests without any leaking.
> 
> I compiled GCC 4.6, build with --enable-libgcj-debug=yes and started
> testing with GC_DUMP_REGULARLY=1.  From the results I have a few
> questions to understand it better.  I am still in a phase of
> pinpointing a minimal program to demonstrate the problem, and I would
> like to get hints as to search further.
> 
> 1. The finalization table entries keeps on increasing up to 39344
> until it is killed, but the objects which are eligible for immediate
> finalization remains 0.  It seems that no finalization takes place.
> Could you give any hints as to what could be the reason for this?  It
> logs:
> 
> ***Finalization statistics:
> 39344 finalization table entries; 48 disappearing links
> 0 objects are eligible for immediate finalization
> 
> ***Static roots:
> From 0x804b284 to 0x804bf1c  (temporary)
> From 0xb716d000 to 0xb7854cdc  (temporary)
> From 0xb55ba92c to 0xb562ddbc  (temporary)
> Total size: 7716356
> 
> 
> 2. There is a fair amount of black-listing.  From reading about the
> GC, I understand that the GC knows what is a pointer and what not
> because there is type information associated with the Java objects.
> So I'd expect no black-listing at all.  It that a right observation?

No.  Objects are scanned precisely, but the stack is not.  Also, depending
on your compilation options, the data segments of your program may be
scanned conservatively.

Andrew.