[Gc] Re: Can GC return unused pages to the OS?
adam at megacz.com
Fri Nov 3 21:58:38 PST 2006
This is a reply to a rather ancient message since that message is the
only mention of UNMAP_THRESHOLD anywhere on the web.
"Boehm, Hans" <hans_boehm at hp.com> writes:
> It can probably be made a bit more aggressive by reducing
> UNMAP_THRESHOLD defined in allchblk.c. If that turns out to be
> useful that knob could be made a bit more accessible.
I've found that the default setting (UNMAP_THRESHOLD=6) can cause
"leak-like" behavior if the application allocates huge tracts of
memory, suddenly drops references to all of it, and then sits in a
fairly idle state.
If the application's allocation activity drops off sharply, the
requisite 6 GC cycles may not occur for a very long time (if ever).
The GC will collect the memory, but will not return those gigantic
pages to the OS. As a result, the application appears to be stuck at
its peak memory usage -- at least from the perspective of the OS.
In this particular case, I found that kludging UNMAP_THRESHOLD=1 fixed
the problem nicely and imposed very little performance overhead (on
As a more long-term goal, I think that something other than the number
of GC cycles should be used as a heuristic. Wall clock time would be
ideal, but this would need to be checked more often than every time a
collection occurs. I'm not sure how to do that without hurting the
> You are right that this is currently only supported by Makefile.direct.
> A patch to configure.in to support USE_MUNMAP would be welcome, but I
> haven't gotten around to it yet.
I can write this up. What is the preferred way of making this
configurable when compiling gcj (since gcj's configure invokes
More information about the Gc