[Gc] Why does GC_max_retries default to zero?
Hans.Boehm at hp.com
Mon Nov 8 20:15:44 PST 2004
I think I've actually gone back and forth on this a few times,
though all of this happened a long time ago.
I agree that in your environment zero is not the right default.
If I remember correctly, the main problem with a larger number is
that debugging a process with runaway allocation gets painful.
Those extra collections tend to involve a lot of swapping, often
making it difficult for a shell to get enough useful cycles to kill
Currently the default is zero with no maximum heap size, and two
if you do set a maximum size. But that's clearly geared toward
development rather than a production environment in which this is
actually an issue. However, I would expect that just setting the
GC_MAXIMUM_HEAP_SIZE environment variable to a sufficiently large
number would also work.
On Fri, 5 Nov 2004, Kenneth C. Schalk wrote:
> An application I maintain which uses the garbage collector has been
> getting steadily heavier use over time. The incidence of failures
> after the message "Out of Memory! Returning NIL!" has been increasing.
> For some time I brushed these off as outside my control. (When the OS
> won't let you mmap any more pages, there's not a whole lot to do.)
> However, I've just now been trying to figure out what we can do about
> it (short of making the application use less memory, which could be
> difficult or impossible).
> I was surprised to find that when the collector decides to expand the
> heap and fails, that the default behavior is to return 0 immediately,
> rather than performing a collection. This seems like a strange choice
> to me, as I had expected that the collector would make a "last ditch"
> collection in this case.
> Obviously an application like mine can set GC_max_retries to a
> different value, and I will probably do that, but 0 seems like a
> strange default to me.
> --Ken Schalk
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc