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

John R Levine johnl@iecc.com
Thu, 22 Jan 1998 17:24:58 -0500 (EST)


> Garbage collection is fundamentally about moving work from the
> programmer to the computer, and the code generator is going to have
> share some of that work. 

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. 

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4  2D AC 1E 9E A6 36 A3 47