GC leaks debugging

Fri Apr 1 09:03:00 GMT 2011

On Fri, Apr 1, 2011 at 10:45, Andrew Haley <aph@redhat.com> wrote:
> 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.

Thanks. I think I can rule the stack out by reviewing/adapting my
test program. I'll do that first.
> Also, depending
> on your compilation options, the data segments of your program may be
> scanned conservatively.

I have to think about this one. Which options are you thinking of?
Erik