Re: GCJ and Boehm GC "Incremental Collection"

[Hans Boehm <Hans dot Boehm at hp dot com>]

As far as I know, the incremental collector works fine in some
applications.  Gcj currently does not appear to be one of them, for
reasons that I think are not completely understood.

There is a quick description of the algorithm and and a reference
in http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html,
in the section "Generational Collection and Dirty Bits".
(Generational and incremental collection are normally quite distinct,
but in this case they use the same underlying algorithms.)

Very quickly, and somewhat approximately, the marker ends up doing
a little bit of work during every allocation.  This by itself can cause
reachable objects to be overlooked, so we have to track updates
made by the mutator in the interim (a "write barrier").  Once this
is finished, we have to again look at modified objects, and make sure
that any objects that are both modified and marked point to marked
objects.  This is normally done in a stop-the-world collection, which
can now be much shorter, since it does much less marking.  (Or we
can iterate the process once or twice more.)

The difficulty comes with tracking updates during marking.  We normally
do that by relying on the virtual memory system, often by protecting
oages and then catching faults.  There is a patch around to use
GetWriteWatch on win32, which works better there.  (The code is in
the 7.0 tree.  There are also Linux kernel patches floating around
to track this in the Linux kernel on some platforms.)

I'm not sure exactly what the options are on Windows CE.  If you
don't have VM support on the platform, this won't work, though you might
be able to generate code to explicitly track modifications.

On most platforms we track updates only for the heap.  If a lot of the
mark time is spent scanning roots, none of this will help.  In that case
you're better off joining the effort to reduce the root size.

Hans

On Mon, 5 Dec 2005, Craig A. Vanderborgh wrote:

> Hello:
>
> We are running a port of GCJ 3.3 w/Boehm GC 6.2 on Windows CE v. 4.2
> (Xscale processor).  As this is a reasonably low-tech (i.e. CRIPPLED)
> platform, we are experiencing long, disruptive delays from "world
> stopped" Boehm GC.
>
> Naturally, there is nothing "wrong" with Boehm GC.
>
> Our challenge is to make this work as best as we can.  What is the
> "Incremental GC" feature of Boehm?  Does it do what the name
> tantalizingly suggests - incremental collection without "world
> stopping"?  If so, this could really help us a lot.  If "incremental GC"
> could help us, what would be needed to use it from GCJ?  We've done a
> lot of work/hacking with GCJ/Boehm, so we're not afraid to plunge in
> where others might fear to tread.
>
> Thanks in advance,
> craig vanderborgh
> voxware incorporated
>