SBCL Internals The pages on this CLiki-driven site can be edited by anybody at any time. No warranty of any kind can therefore be made; any implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed

Bill Newman's observations about GC as of sbcl-0.7.1:

• The split between gencgc.c and gc.c and purify.c is a copy-and-paste horror. IMHO the best first step in improving either gc.c or gencgc.c would be to factor out the shared code with a clean interface.
• It might not be too hard to port gencgc.c to non-X86 architectures. It seems like a shame not to take advantage of the increased GC exactness possible on the non-register-poor architectures, but I expect that conservative generational GC would perform better than exact stop-and-copy GC.
• There's also the old gengc.c code from CMU CL. It might be possible to port that. (I have no idea how hard that would be, or how good the result would be, I just don't want people to overlook gengc.c just because its source isn't in the SBCL tree.)
• I've sometimes had problems with gencgc.c seeming annoyingly conservative about what it collects, enough that I looked through the code for possible causes. One possible cause is that objects on the same page as code objects don't seem to get moved (and thus don't get cleaned up when they're unused). I haven't measured it, but there could easily be a whole lot of objects of this kind. If anyone wants to improve gencgc.c, then this might be something to look at.

This page is linked from: GC  

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively