This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]