This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: GC leaks debugging
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.