maximum memory for gcj-compiled executable?

Mon Mar 24 16:25:00 GMT 2003

On 2003年3月24日, 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