Re: Can GC return unused pages to the OS?

[Adam Megacz <adam at megacz dot com>]

The following message is a courtesy copy of an article
that has been posted to gmane.comp.programming.garbage-collection.boehmgc as well.


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-VXdhtT5mjnY@public.gmane.org> 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
mingw32).

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
allocation fast-path.

> 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
boehm-gc's configure)?

  - a