GC leaks debugging

Erik Groeneveld erik@cq2.nl
Wed Apr 6 14:30:00 GMT 2011

>> The tests work fine on OpenJDK.  What could cause GCJ to grow the heap
>> infinitely?
> I don't know because you won't show me the tests.

Yeah, of course, sorry.  I forgot to tell a few things.

This problem has been bothering me quite some time now, and I decided
to solve it once and forever.  I have written many different test, but
I am still not able to pinpoint a simple program to demonstrate the
results.  The problem occurred initially while using Lucene, but later
on also with Owlim.  Having written all kinds of test programs with
Lucene, from doing almost nothing to fully fletched indexing, I can
make no definite conclusions yet.

I am now circling around the problem, trying to enclose it from
different sides and I seek your help for giving me hints on what to
look for.  It is not lightly that I decided to bring it into this
mailing-list, knowing that it would claim many peoples time.

Now the test I am running is attached.  It indexes a very simple
document with a unique id each, first assuring is it deleted.  And
each loop, it reopens the index-reader and searcher.  This test starts
to get in trouble above 10,000,000 loops (documents).  The problem is
that when I remove code (I tested systematically), it only takes
longer for the heap to explode. The only test that ran properly was
when I only created Documents and not index them.  So perhaps it has
to do something with I/O.

I built the lucene dso with (full script attached):

gcj -shared -fPIC $JARFILE -o liblucene-core.so -Lgccinstall/lib -lgcj
-findirect-dispatch -fno-indirect-classes

and the test with (full scipt attached):

g++ -O0 -fPIC -g -o test test.cpp \
    -I../include/lucene \
    -L../gccinstall/lib64 \
    -lgcj \
    -L.. \
    -llucene-core \
    -findirect-dispatch \

GCC being the 4.6 branch from SVN, build with:

../gcc-4_6-branch/configure --prefix=$installdir --disable-multilib

I understand that this is a high-level approach, and you'll like a
smaller test that demonstrates the problem.  But I don't have that
yet.  Any suggestions you can come up with at this level are more than

Meanwhile, I dive deeper into analysis of the heap.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.cpp
Type: text/x-c++src
Size: 4187 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20110406/4c0ed0d8/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildlucenelib.sh
Type: application/x-sh
Size: 2022 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20110406/4c0ed0d8/attachment.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildAndRun.sh
Type: application/x-sh
Size: 350 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20110406/4c0ed0d8/attachment-0001.sh>

More information about the Java mailing list