[gclist] Thread safe GC

[Hans Boehm]

On Apr 14,  8:01am, Thomas Weitzel wrote:
> I'm interested in the topic of thread-safe garbage collection / object
memory.
> More concrete: Multiple independent operating system threads access the
object
> memory, the garbage collector either runs as an additional thread or is
started
> by a user thread when needed. A good example of this type of system is Java.
>
> I looked into Paul Wilsons survey article, but found little on that topic.
Could
> you point me to more information, preferrably on the web?

There are many systems that do this, including ours
(http://reality.sgi.com/employees/boehm_mti/gc.html), Cedar, Modula-3, Java,
and no doubt many others.

With a sufficiently cooperative thread system, it is not very difficult.  In
the simplest case, allocation acquires a lock.  The garbage collector is
occasionally invoked during garbage collection.  The garbage collector acquires
any other locks it may need, and then stops the other threads before it does
its thing.  (Having tried it both ways, I'm not a great fan of a separate GC
thread. It's too hard to ensure that the collector remains robust and never
falls behind.)

Things that make life a bit harder:

- pthreads are not sufficiently cooperative.  (Many pthreads implementations
are, however.)  My impression is that win32 threads are adequate, but only if
you rely on obscure information that's not apparent from the documentation.
 (I.e. the situation is basically the same as with pthreads, but there are only
two implementation that anybody cares about, and they come from the same
vendor.)

- you may not want to stop the world for the whole collection.  You want an
incremental collector. (Ours does support this in some cases.)

- for a massively parallel system, you want to allow more than one thread doing
useful GC work at the same time.  I don't know of too many implementations that
support this.  (One of ours does, but only to a very small extent.)  I don't
believe there are any fundamental problems here.  But I suspect it's hard to
get the details right.

Hans





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