From: David Daney <ddaney@caviumnetworks.com>
To: Andrew Haley <aph@redhat.com>
Cc: Erik Groeneveld <erik@cq2.nl>, java@gcc.gnu.org
Subject: Re: GC leaks debugging
Date: Wed, 06 Apr 2011 18:39:00 -0000 [thread overview]
Message-ID: <4D9CB342.1070300@caviumnetworks.com> (raw)
In-Reply-To: <4D9CB200.2000103@redhat.com>
On 04/06/2011 11:33 AM, Andrew Haley wrote:
> On 04/06/2011 03:29 PM, Erik Groeneveld wrote:
>>>> 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.
>
> Just as a clue: there are thousands of unclosed FileInputStreams and
> FileDescriptors. At a mad guess, someone is not closing their files but
> hoping that finalization will do it instead.
>
> I was using:
>
> gnu::gcj::util::GCInfo::enumerate(JvNewStringUTF("LuceneDump"));
>
> and
>
> /usr/local/bin/gc-analyze TestDump001
>
> Eventually, I get a
>
> Exception in thread "main" java.lang.IndexOutOfBoundsException
> at java.nio.Buffer.checkIndex(Buffer.java:331)
>
> from gc-analyze. I may be able to find out what is causing that.
>
:-(
Sorry about that. It shouldn't crash, but unfortunately I don't have
the time to fix it right now.
David Daney.
next prev parent reply other threads:[~2011-04-06 18:39 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-01 8:39 Erik Groeneveld
2011-04-01 8:45 ` Andrew Haley
2011-04-01 9:03 ` Erik Groeneveld
2011-04-01 9:34 ` Andrew Haley
2011-04-02 0:27 ` Boehm, Hans
2011-04-02 9:39 ` Erik Groeneveld
2011-04-03 17:15 ` Erik Groeneveld
2011-04-03 18:00 ` Erik Groeneveld
2011-04-04 8:13 ` Andrew Haley
2011-04-04 8:53 ` Erik Groeneveld
2011-04-04 9:48 ` Andrew Haley
2011-04-05 4:44 ` Boehm, Hans
2011-04-05 8:58 ` Andrew Haley
2011-04-05 6:50 ` Erik Groeneveld
2011-04-05 9:02 ` Andrew Haley
2011-04-05 12:02 ` Erik Groeneveld
2011-04-05 12:55 ` Andrew Haley
2011-04-06 14:30 ` Erik Groeneveld
2011-04-06 18:33 ` Andrew Haley
2011-04-06 18:39 ` David Daney [this message]
2011-04-07 17:43 ` Erik Groeneveld
2011-04-08 8:12 ` Erik Groeneveld
2011-04-08 13:56 ` Andrew Haley
2011-04-08 15:35 ` David Daney
2011-04-08 15:53 ` Erik Groeneveld
2011-04-08 15:57 ` Andrew Haley
2011-04-08 15:48 ` Erik Groeneveld
2011-04-09 1:17 ` Boehm, Hans
2011-04-09 8:47 ` Andrew Haley
2011-04-09 10:56 ` Erik Groeneveld
2011-04-10 11:03 ` Erik Groeneveld
2011-04-12 18:43 ` Erik Groeneveld
2011-04-13 8:11 ` Andrew Haley
2011-04-13 12:11 ` Bryce McKinlay
2011-04-13 14:27 ` Andrew Haley
2011-04-14 8:36 ` Erik Groeneveld
2011-04-14 8:43 ` Andrew Haley
2011-04-14 10:02 ` Erik Groeneveld
2011-04-14 10:50 ` Andrew Haley
2011-04-15 7:32 ` Erik J Groeneveld
2011-04-01 17:41 ` David Daney
2011-04-02 16:21 ` Erik Groeneveld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D9CB342.1070300@caviumnetworks.com \
--to=ddaney@caviumnetworks.com \
--cc=aph@redhat.com \
--cc=erik@cq2.nl \
--cc=java@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).