GC leaks debugging
Fri Apr 1 09:03:00 GMT 2011
On Fri, Apr 1, 2011 at 10:45, Andrew Haley <firstname.lastname@example.org> wrote:
> On 01/04/11 09:39, Erik Groeneveld wrote:
>> 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
>> ***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?
More information about the Java