So, last night I did some hacking on CMUCL's garbage collector, as advertised. The work I've done is pretty minimal at this point: just adding some additional statistics such as time spent collecting, page faults incurred, etc. I have a plan to tune up the garbage collector and these are the first baby steps in that direction. I think it'd be cool to let the user choose one of several GC policies: fast (generally short pauses), real time (very short pauses, 5-8ms in general), throughput (reasonable pauses but minimizing the total time spent collecting rather than the length of any one GC), and a spiffy auto GC policy that figures out which policy would be best for the current session.
CMUCL's garbage collector is written in C, and I was somewhat resigned to doing this tuning work in C too. Last night I had an "Aha!" about this: don't implement the policy code in C, which would be a drag, but export statistics and tunable parameters from the C implementation into Lisp. Lisp code that runs in an after-gc-hook then analyzes the statistics from previous GCs and diddles the parameters appropriately. Much better; after all, if I wanted to program in C I'd be hacking on the Gimp or something :)
A motivating factor for going in this direction is the fact that working on CMUCL's C code is a pain in the rear. CMUCL is a combination of a small C/assembly program providing some primitive services (such as memory allocation and garbage collection) and a much larger image of Lisp code and data. The Lisp code knows the addresses of important routines in the C code so they can be called from Lisp, but when the C code changes the addresses of those functions change too and the Lisp image has to be rebuilt. How that's done is a subject for another time, but it's somewhat more involved than just typing "make".