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: Out of memory problem


Yes indeed I did (forget).  Actually, I didn't even know about it until
I started poking around on Friday.  My example works fine now.

Thank you Hans and Jeff for your comments.
--Suresh

--- "Boehm, Hans" <hans_boehm@hp.com> wrote:
> 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
> > > 
> > 

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


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