From: Andrew Haley <aph@redhat.com>
To: Erik Groeneveld <erik@cq2.nl>
Cc: "Boehm, Hans" <hans.boehm@hp.com>, "java@gcc.gnu.org" <java@gcc.gnu.org>
Subject: Re: GC leaks debugging
Date: Wed, 13 Apr 2011 08:11:00 -0000 [thread overview]
Message-ID: <4DA55ABC.1040505@redhat.com> (raw)
In-Reply-To: <BANLkTik275CnV8KDypHKHwUR18wf9SxhTg@mail.gmail.com>
On 12/04/11 19:42, Erik Groeneveld wrote:
> Hans, Andrew,
>
> Having concluded for myself that fragmentation causes the heap to grow
> indefinitely, it tried to find a workaround. Because changing
> different (environment-, build-, runtime-) variables didn't help, I
> started looking at the code itself.
>
> I found that all memory allocation calls from GCJ eventually come down
> to GC_allochblk(), so I started gathering some statistics about it.
> It turned out that it wasn't called that often at all, so I just added
> a forced collect to see if my assumptions were right, risking much
> slower runtime of course. I tried:
>
> @@ -50,6 +52,13 @@
> /* Do our share of marking work */
> if(GC_incremental && !GC_dont_gc)
> GC_collect_a_little_inner((int)n_blocks);
> +
> + if (n_blocks >= 8) { // 32 kB and bigger often occur in fragmented heaps
> + GC_gcollect_inner();
> + printf(">>> forced collect <<<\n");
> + }
> +
> h = GC_allochblk(lw, k, flags);
> # ifdef USE_MUNMAP
> if (0 == h) {
>
> I ran my test, and ignored it slowness (only noticing that it was not
> so much slower). But it works:
>
> Before: 29,000,000 docs, 820 MB heap, OOM.
> After: 67,000,000 docs, 490 MB heap. Disk full ;-(
>
> So frequent collection can certainly avoid fragmentation in this case.
>
> Now the most curious of all: it is even faster as before:
>
> Before: 1306 docs/second
> After: 1582 docs/second
>
> Apparently, it is better to collect a small heap more often than a
> large heap less often.
This is very interesting.
> Now this hack helped me to assert my assumptions, but it also works
> well enough that I am going to try it to relieve some of the stress
> that has been plaguing some productions systems for quite some time
> now.
>
> Meanwhile, I'd like to pursue a better solution - less of a hack. Any
> interest in helping out?
Before you go any further, it's worth remembering that you're using an
old version of the GC. I've been told that "Of course, [the new gc]
will require modification of boehm.cc in GCJ" but not why.
It looks like you're making progress, but I urge you to move to the
new gc or your time may be wasted on the old one.
Andrew.
next prev parent reply other threads:[~2011-04-13 8:11 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
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 [this message]
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=4DA55ABC.1040505@redhat.com \
--to=aph@redhat.com \
--cc=erik@cq2.nl \
--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).