RE: Out of memory problem

["Boehm, Hans" <hans_boehm at hp dot com>]

It turns out it's a feature.   You clearly forgot to also set GC_max_retries to some nonzero value :-) .  (So did I when I looked at your code and tried this.)

If GC_max_retries is zero, it will fail immediately instead of trying a GC when it runs out of space.  That's probably not what you want it to do if you artificially limit the heap size.  (Unfortunately, it sometimes is, e.g. if you're trying to debug a process that you know has a runaway space leak.)

I added a way to limit the heap size through an environment variable.  It will eventually make it into the gcc tree.  It will implicitly set GC_max_retries.

Hans

> -----Original Message-----
> From: Boehm, Hans [mailto:hans_boehm@hp.com]
> Sent: Thursday, June 27, 2002 3:27 PM
> To: 'Jeff Sturm'; Suresh Raman
> Cc: 'java@gcc.gnu.org'
> Subject: RE: Out of memory problem
> 
> 
> This doesn't look right to me, either.  I'll try to look at 
> it as well.
> 
> This is a fairly pessimal test case for gcj, since "small" 
> objects are allocated in 4K chunks.  You'll only be able to 
> fit 3 1024 byte arrays in a chunk, thus wasting nearly a 
> quarter of the space.  But that still doesn't explain what's 
> going on here.
> 
> I don't think the collector should fail just because it tried 
> to expand past the maximum heap size.  It should try to make 
> do with less instead.  Thus GC_free_space_divisor shouldn't 
> have a significant impact, though it would be interesting to 
> know whether it does.
> 
> Hans 
> 
> > -----Original Message-----
> > From: Jeff Sturm [mailto:jsturm@one-point.com]
> > Sent: Thursday, June 27, 2002 12:59 PM
> > To: Suresh Raman
> > Cc: java@gcc.gnu.org
> > Subject: Re: Out of memory problem
> > 
> > 
> > On Thu, 27 Jun 2002, Suresh Raman wrote:
> > > But, when I limit the maximum heap size of the program to 
> > 4MB* and run
> > > the same program again, I get "Warning: Out of Memory!  Returning
> > > NIL!" errors.   It happens nearly everytime during the 
> 768th pass in
> > > the loop.  The total heap memory is almost at 4M and the free heap
> > > memory is at 0, when the error happens.  Given that the 
> program does
> > > not use more than 2MB at any time, I expect it to run without any
> > > problems within 4MB.  This is unfortunately not the case.
> > 
> > I'm not quite sure why the explicit GC would help you, since 
> > the collector
> > will attempt a full collection anyway if it cannot grow the heap.
> > 
> > For tuning the collector I've found it helpful to build 
> > without -DSILENT,
> > and you might also arrange to call GC_dump() at the point 
> of failure.
> > That'll help to understand what decisions the collector is making.
> > 
> > Also see the documentation for GC_free_space_divisor.  
> > Increasing this can
> > limit heap growth to some extent.
> > 
> > Jeff
> > 
>