GC leaks debugging

Sat Apr 2 09:39:00 GMT 2011

[...]
> Note that in the information you posted, the GC was scanning around 7.5MB of roots conservatively.  It might be worth checking what those regions are.
It seems it come from libgcj. This is now my minimal program:
#include <gcj/cni.h>
void _Jv_RunGC(void);
int main(int argc, char *argv[]) {
 JvCreateJavaVM(NULL);
 _Jv_RunGC();
 //JvAttachCurrentThread(NULL, NULL);
}
I compile the test with:
g++ -O0 -fPIC -g -o test test.cpp -L../gccinstall/lib -lgcj
And run with:
export GC_DUMP_REGULARLY=1
export GC_BACKTRACES=10
./test
Only linking and initializing GCJ gives the log as attached. The 7.5
MB root is already present. And it gives nearly 2000 blacklisting
messages, resulting in a heap with 10 of 12 sections 100% blacklisted
and the other 2 already significantly polluted.
Since the program has yet to begin, it seems that the race is about to
start with one party on a severe penalty. ;-)
> The number of black-listed pages seems really high to me.  Is the collector configured for too small a heap?
I use GCC 4.6 (svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch) and
gc is build with LARGE_CONFIG and PRINT_BLACK_LIST.
> What's the platform?
Linux 2.6.32-5-686-bigmem with 4 GB memory. I understand that the
changes of misidentifiying pointers are smaller on a 64 bits machine,
so I also ran (lots of) tests on an AMD64 machine, however I got the
same problems with exploding heaps consistently on both architectures.
 I attached a typical explosion graph.
Lastly, I have read this thread about "leak with finalizers"
(http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/748)
and it seems that something quite similar happens with GCJ. I also
tried to explicitly call GC_gcollect as suggested, which delayed but
did not contain the explosion. However, I now think that it might be a
good idea to explore this 7.5 MB root that GCJ is starting out with.
Do you have any hints on how to find the sources of these roots?
Erik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gc-log.tgz
Type: application/x-gzip
Size: 42082 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20110402/cb556813/attachment.bin>