This is the mail archive of the
mailing list for the Java project.
RE: [Fwd: Success with Nutch & GCJ]
- From: "Boehm, Hans" <hans dot boehm at hp dot com>
- To: <tromey at redhat dot com>, "Andrzej Bialecki" <ab at getopt dot org>
- Cc: <java at gcc dot gnu dot org>
- Date: Fri, 10 Feb 2006 10:17:10 -0800
- Subject: RE: [Fwd: Success with Nutch & GCJ]
> From: Tom Tromey
> Andrzej> GC Warning: Repeated allocation of very large block
> (appr. size 6578176):
> Andrzej> May lead to memory leak and poor performance
> Yeah, we know about this. I don't know of a general solution though.
> What version of gcj are you using? If you are using 4.0.x,
> and if this message is coming via the http protocol handler,
> then the problem is fixed in 4.1.
From later messages, it sounds like this wasn't the case.
You might be able to determine who is doing the allocation by setting a
break point in GC_default_warn_proc, and looking at the call stack. It
looks like something may be repeatedly allocating and dropping 6-7MB
blocks. Although gcj will react worse to that than most commercial VMs,
I would expect to see performance improvements on any VM if you could
avoid doing that, e.g. by allocating it once and keeping it around,
particularly if it contains no references. (If it does contain
references, you need to make sure that you're not accidentally keeping
other stuff around in the process.)
I'd have an easier time understanding the memory behavior with the log
generated by setting the GC_PRINT_STATS environment variable. I suspect
the issues there are also caused by these very large block allocations.
This was presumably on 32-bit X86? On a 64-bit platform, I would expect
things to be at least somewhat better.