[gclist] Re: PPC & GC, or GC and threads
Fri, 23 Jan 1998 13:34:04 +0900 (JST)
> 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
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).