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

[Taura Kenjiro]

 > 
 > Well, sure, but since GC is a relatively infrequent activity compared to
 > evaluating expressions, and on architectures without direct addressing,
 > code that never hides a pointer can be difficult or bulky to generate. 
 > You can imagine other ways to deal with this problem, e.g., sort-of-soft
 > preemption points. 
 > 
 > 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.
 > 
 > I freely admit that this is a gross disgusting hack, but anyone who's
 > proposing conservative GC has already waived his right to complain on that
 > basis. 
 > 

My impression is that this approach requires every components
(threads/code generator/GC) be tightly integrated.

You will be interested in Dr. Boehm's 1996 PLDI paper, "Simple Garbage
Collector Safety."  There, the basic approach is, for every indexing
accesses like p[i], the compiler generates a code that keeps the base
pointer (i.e., 'p') reachable until the indexed address (i.e., 'p + i'
in this case) is computed.  There are interesting tricks that do this
by C-to-C transformation (I don't remember the details).