maximum memory for gcj-compiled executable?

Mon Mar 24 23:34:00 GMT 2003

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 2003年3月24日, Jeff Sturm wrote:
> 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
>
-- 
Hans Boehm
(hboehm@hpl.hp.com)