RE: Setting memory-chunk-size claimed when free-memory approaches zero?

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

There's another important variable here.

When GC_collect_or_expand decides to expand the heap, it first
tries to expand the heap by it's desired amount.  If that fails,
it tries to expand by what it things it needs to satisfy the
current allocation request.  If both of those fail, it tries
to garbage collect GC_max_retries times and then gives up.

Unfortunately, there seems to be no universally good value
for GC_max_retries.  Setting it too large (or nonzero even)
tends to force useless GCs when you're debugging a program with
run-away memory usage.  And these GCs tend to trigger lots of
paging, making it hard to kill the process, and even harder
to get a core dump.  Setting it to zero results in the
behavior described here.

The current default behavior is to set GC_max_retries to zero,
unless GC_MAXIMUM_HEAP_SIZE is set, in which case it's two by
default.  This makes a bit of sense, since if GC_MAXIMUM_HEAP_SIZE
is set, presumably it's set to avoid paging disasters.  (On an
embedded platform, paging is probably not an issue, but you do
want to set GC_MAXIMUM_HEAP_SIZE anyway, which should
give you reasonable behavior.)

If you are really trying to adjust how aggressively the GC grows the
heap, then setting GC_free_space_divisor instead or in addition
is a good idea.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> David Daney
> Sent: Wednesday, November 24, 2004 10:13 AM
> To: Bryce McKinlay
> Cc: Martin Egholm Nielsen; java@gcc.gnu.org
> Subject: Re: Setting memory-chunk-size claimed when free-memory
> approaches zero?
> 
> 
> Bryce McKinlay wrote:
> >>
> >>But neither happens - my application gets terminated by the Linux 
> >>kernel...
> >>
> >>Now, the real question: Is there a way to circumvent this? Can I 
> >>configure the chunk-eating-mechanism so that it does not allocate 
> >>chunks larger than, say, 100kb at a time...
> > 
> > 
> > 
> > GCJ's garbage collector does not, by default, set a maximum 
> heap size. 
> > This means that it will keep requesting more memory from 
> the system, if 
> > required, until VM is exhausted. On Linux systems this 
> might mean that 
> > the kernel kills your application.
> > 
> > The way to avoid this is to set the maximum heap size to 
> the maximum 
> > amount of memory you want your application to use. You can 
> do this by 
> > setting the environment variable GC_MAXIMUM_HEAP_SIZE=<bytes>
> > 
> If you do set GC_MAXIMUM_HEAP_SIZE, then you should also 
> probably set the
> divisor to a larger value (I forget the exact name of the 
> variable).  If
> you use the default divisor value with a limited memory 
> setting you can run
> into situations where you get OutOfMemoryError which can be 
> eliminated with
> a larger divisor.  We use a divisor value of 20.
> 
> David Daney.
> 
>