public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Erik Groeneveld <erik@cq2.nl>
To: Andrew Haley <aph@redhat.com>
Cc: java@gcc.gnu.org, "Boehm, Hans" <hans.boehm@hp.com>
Subject: Re: GC leaks debugging
Date: Fri, 08 Apr 2011 15:48:00 -0000	[thread overview]
Message-ID: <BANLkTi=7SEhVZw7b48x46HF9Sv6zWmt4Qw@mail.gmail.com> (raw)
In-Reply-To: <4D9F13E9.7000106@redhat.com>

>> The last good dump I have from the test after 12 million cycles (it
>> then got killed) has nothing like File stuff at all.  A also saw other
>> suspicious objects, but they all disappeared later on.  The collecter
>> really works wel!
>>
>> Next hypothesis:
>> From analyzing graphs from the logs and comparing them to those of the
>> OpenJDK, I get the feeling that the collector looses control by not
>> collecting often enough.
>>
>> The heap is quite unused/free, and remains so during the process.  It
>> seems that at some point, the heap fills up very quickly, and then the
>> collector decides to expand the heap instead of collecting (the
>> algorithm for deciding this seems rather complicated).  However, a
>> larger heap also causes the collector to collect less frequently.  So
>> the next time the heap fills up rapidly, it again decides to expand
>> the heap, again causing less frequent collections.  And so on.  I´ll
>> post the graph data in a separate post if you want it.
>
> That makes sense as an explanation.
>
> It looks, then, as though there isn't a leak at all.  The collector
> does what it's supposed to do.  There is always the risk of this with
> any non-compacting dynamic memory allocator.

Yes, a non-moving collector has its limits, but I have still hope for
improvement.

>> And the next hypothesis:
>> Perhaps the program allocates many different (possibly large) sizes,
>> which remain on the free list, but cannot be used because the next
>> objects requested are slightly bigger.  I have to study this somewhat
>> more.
>
> I wonder.
>
>> Just two questions:
>> 1. What is a reasonable number of heap sections?  I have 131 here.
>> 2. What is a reasonable number of free lists?  I have 60, which have
>> 13,000+ entries.

I found from the code that 60 is the upper bound.  And 13,000 seems to
be a lot to me.  Altogether, the free space is about 700 Mb, of a 900
Mb heap.

Hans, is there a limit on the length of the free lists?
Adjacent blocks of the same size are coalesced; is there also
coalescing of blocks of different sizes at some point?

I tried a build with with USE_MUNMAP, hoping that would help the
collector clean up free-list, but I am still testing.

> Paging Hans Boehm.  can you suggest ways to get the system to GC more
> frequently?  Would doing so avoid this scenario?
>
> Andrew.
>

  parent reply	other threads:[~2011-04-08 15:48 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
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 [this message]
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='BANLkTi=7SEhVZw7b48x46HF9Sv6zWmt4Qw@mail.gmail.com' \
    --to=erik@cq2.nl \
    --cc=aph@redhat.com \
    --cc=hans.boehm@hp.com \
    --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).