[gclist] Thread safe GC

[Hans Boehm]

On Apr 15,  8:18am, stuart  (yeates) wrote:
> Subject: Re: [gclist] Thread safe GC
>
> > If I can't stop and restart threads I'm totally stuck. I can't really
> > collect for running threads.
>
> I'm speculating here, but, in theory, shouldn't you be able to
> collect in the multithreaded situation using thread priorities ?
>
> What i mean is, at the start of the collection, raise the priority
> of the collector thread to n+1 (where n in the previous highest
> priority, and high n = high priority), and scan the stacks of threads
> at piority n. When all stacks at priority n have been scanned, lower
> the collector thread to priority n and start scanning the stacks
> priority n-1.
>
> This wouldn't require the ability to stop threads, but if non-gc threads
> changed their priorities, you'd be lost.
>
> stuart
>
This fails on a multiprocessor, unless you have at least as many GC threads as
processors.  Even then, I wouldn't recommend it.  The experience at PARC was
that, at least for non-real-time applications, thread systems that strictly
obeyed priority were painful to use.  It's too easy to end up with high
priority threads waiting to be signalled by low priority ones which never get a
chance to run.  Later versions of Cedar intentionally ran low priority threads
occasionally, even if there were higher priority runnable threads.  (This was
implemented with a high priority thread that woke up occasionally and performed
a directed yield to a random thread.  It follows that the above scheme also
breaks in the presence of directed yield.)  It's usually much more convenient
to view priority only as a guideline.  (I suspect hard real-time systems are
completely different.  Trying to design a thread system for both may be a
mistake.)

Also note that you can't always easily restart the highest priority threads
after the GC is done scanning the stacks.  At least if this is C code, they
could swap pointers with a stack of a lower priority thread, causing you to
lose a pointer.  You need a fully consistent snapshot of everything that
doesn't have a write-barrier.

Hans




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