Incremental GC (was RE: Projects)

Sat May 13 12:37:00 GMT 2000

Thanks for the reply. I can see how this would be much better for
interactive graphical applications. I'm working in the embedded
realm, where there is no paging, multi-threading is a given, the heap
size is fixed an know, and the application is more predictable. It
may still be better to do work in the allocator, but I'm not really
sure. I'm certainly not adverse to using your collector or switching
mine to run as part of the allocator. It's written as an event-driven
state machine now, so switching would be fairly easy. I planned ahead :-).
I did plan on auto-tuning based upon free heap space, but I haven't
finished that yet.
I did try for a while to get your collector working, I looked at the
insides for a while so I'm a little familiar with how it works. I
could not make the incremental mode collect anything at all on Linux
PowerPC. It also seemed to require a full mark-and-sweep periodically
as evidenced by the GC_full_freq variable. We need a purely
incremental collector; we cannot take the delay of a full cycle.
Am I naive to think that this can be done? What I have now seems to
work well, I've run it for days at a time without problems. Reading
various papers on GC never seemed to bring this up as a problem. But
if I am looking at a fundamental design problem, knowing sooner is
better than knowing later.
Corey
"Boehm, Hans" <hans_boehm@hp.com> writes:
> 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
> >