Incremental GC (was RE: Projects)

[Boehm, Hans]

I would argue that you need to somehow tie the GC rate to the allocation
(and perhaps pointer assignment) rate.

The Xerox PARC PCR collector ran in its own thread.  Initially it did so in
a fairly ordinary thread.  That turned out to be unreliable, since it would
fall behind for allocation intensive code, resulting in huge heap growth.
Subsequently we used thread scheduling hooks to speed up the GC thread
during high allocation periods.  That was better, but still not great.  In
particular, it's hard to keep the collector from falling behind when you
start paging, since the mutator tends to have better locality, and thus
tends to make better progress.

Our current incremental collector basically does some GC work for each
allocation, currently completely in the allocating thread.  That seems far
more robust.  It also works in single-threaded environments.  The downside
is that the code is hairy, in that it needs to maintain explicit state
instead of using a thread abstraction.  It is likely to get more
complicated, since I eventually want to allow more than one concurrent
marker, even during incremental collections.

Hans

> -----Original Message-----
> From: Corey Minyard [ mailto:minyard@acm.org ]
> Sent: Tuesday, May 09, 2000 2:51 PM
> To: Boehm, Hans
> Cc: Jonathan P. Olson; Tom Tromey; green@cygnus.com;
> java-discuss@sourceware.cygnus.com
> Subject: Re: Projects
> ...
> But the scary part is keeping the mutator under control.  An
> application with a very active mutator would be a big problem for an
> incremental collector in this memory space.  We have been trying to
> write our application to be nice to the GC, so we should be ok, but
> it's still scary, because if we hit a full mark and sweep, that's
> around 15 seconds we are out, which is too long for our application.
> 
> Corey
>