Out of memory problem

[Boehm, Hans]

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
>