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".