[gclist] Looking for a garbage collector

[Hans Boehm]

On Jul 1,  9:18am, Patrick E. Krogel wrote:
> Subject: Re: [gclist] Looking for a garbage collector
> > Dear colleagues!
> >
> > For a project I'm looking for a garbage collector
> > with the following properties:
> >
> > ...
> > - it's incremental and running as a thread concurrently with
> >   the main thread(s) (as in Java)
> >
> > Does anybody know such a collector or a collector
> > that fulfils some of the requirements above?
>
> Check out "http://reality.sgi.com/employees/boehm_mti/gc.html"
> It appears to meet most of the criteria except the last one,
> running as a thread.  I haven't checked the efficiency yet, but
> it uses a mark and sweep algorithm.
>
There once was a version of this collector that ran in a thread, at least if
the thread in question was a Xerox PCR thread.  (You can still get from
ftp://parcftp.xerox.com/pub/pcr.)

There are cases in which this is a good idea, but I've generally arrived at the
conclusion that it isn't.  The fundamental problem is that this scheme is not
robust against a very rapidly allocating thread without some fairly gross
scheduling hacks.  The rapidly allocating thread runs fast, causing either
frequent world-stop garbage collections or uncontrolled heap growth.  In either
case, other threads tend to suffer badly.  It seems to make more sense to run a
collector incrementally in the allocating thread, such that other threads can
mostly continue to operate during a collection.  That's what more recent
versions of my collector do.  That way the fast allocating threads also do the
lion's share of the GC work, and the scheduling tends to take care of itself.

Hans




-- 
Hans-Juergen Boehm
boehm@mti.sgi.com