GC leaks debugging

Andrew Haley aph@redhat.com
Fri Apr 1 08:45:00 GMT 2011


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.



More information about the Java mailing list