This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: maximum memory for gcj-compiled executable?
- From: Hans Boehm <Hans dot Boehm at hp dot com>
- To: Jeff Sturm <jsturm at one-point dot com>
- Cc: Erik Poupaert <erik dot poupaert at chello dot be>,Per Bothner <per at bothner dot com>, GCJ Java <java at gcc dot gnu dot org>,Ranjit Mathew <rmathew at hotmail dot com>
- Date: Mon, 24 Mar 2003 15:46:24 -0800 (PST)
- Subject: RE: maximum memory for gcj-compiled executable?
The standalone versions of the collector now support a
GC_MAXIMIMUM_HEAP_SIZE environment variable. Unfortunately that
doesn't seem to have propogated into libgcj, yet.
Hans
On Mon, 24 Mar 2003, Jeff Sturm wrote:
> On Mon, 24 Mar 2003, Erik Poupaert wrote:
> > I would need commandline options initheapsize=... maxheapsize=... to keep a
> > lid on the memory consumption of a gcj executable. For a GUI it doesn't
> > really matter, but the current unconstrained memory consumption is quite
> > dangerous for server processes.
>
> If your process runs out of memory it'll probably crash. But that's
> better than making the entire server unresponsive.
>
> I agree that some kind of -mx/-ms options to gcj would be useful. You
> might submit a PR for this enhancement (or a patch).
>
> Normally the boehm-gc collector used by gcj will collect long before
> system memory is exhausted (it normally prefers collecting vs. growing the
> heap, but the algorithm is slightly more complex than that). So it's
> clear something is going wrong in your case.
>
> I don't remember if you said... does the application run correctly under
> the JRE? (I.e. not leak memory?)
>
> > Another question revolves around the fact that you have to allow a gcj
> > process to produce quite a bit of garbage, if you want any performance from
> > it. Otherwise it could spend much of its time garbage collecting.
>
> That's true. The cost of collection is related to the heap size and
> root set. See the comments about GC_free_space_divisor in
> boehm-gc/include/gc.h.
>
> You can tune the default behavior somewhat by adjusting GC_free_space_divisor
> in your application.
>
> > I wonder
> > what the characteristics are of the tradeoff? How is the curve of %garbage
> > versus %performance?
>
> I find the behavior varies greatly by application. Some applications
> benefit from incremental GC more than others, also. (Incremental GC is
> currently disabled by default.)
>
> Have you read the information at Hans Boehm's GC site, in particular
> http://http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html?
>
> Jeff
>
--
Hans Boehm
(hboehm at hpl dot hp dot com)