[gclist] Re: PPC & GC, or GC and threads

[Mike Gunter]

 > Here's a hand-waving sketch of how you might do it: we assume that any
 > thread that's not runnable because it's waiting for something is in a
 > clean state, so the issue is to get all the runnable threads clean.  Have
 > the compiler create a list of points where the state is clean, and either
 > mark it by putting no-ops in the code or in a symbol table that's loaded
 > at runtime.  Then when one thread decides it wants to GC, it looks at all
 > the other runnable threads, scans ahead from the saved PC to the next
 > clean point (forking at branches if need be) and sticks breakpoints at the
 > clean point(s) found.  Then it resumes the other threads until they all
 > breakpoint, undoes the mess, and then does the GC.  This trades off more
 > work at GC time for less work in normal code, but that's usually a win.

Nice trick!  Two refinements:

  * The compiler probably needs to guarantee a bounded number of
    instructions until executing a clean point.

  * You can dismiss with clean points where there's allocation by
    using the old trick of fiddling with the allocation data
    structures to make it look like the heap is exhaused.

Right?

		mike