[gclist] Compiler specialized GC's

[Dave Lloyd]

>I'm curious if there's been any research for compiler supported, GC
>specialization. That is has then been any work on compilers that at compile
>time generate a specialized/GC runtime system to take advantage of program
>specific properties. For example, if you don't mind losing modularity, one
>could imagine a compiler analyzing all the different kind of heap objects a
>program could allocate and hard coding a specialized GC that was specialized
>to collect the object, rather than interpreting bitmaps or other type
>information at runtime, one could also imagine using specialized copying
>routines too, if you're gc scheme need to copy. I guess, my real question is
>are these kind of optimizations going to be swamped by other factors like VM
>interactions or tagging/untagging costs.

Our GC generates a marking routine for each type in the system rather than 
interpreting a type description during GC. Makes for quite a fast traversal. 
You don't need to lose any modularity though - each module generates its 
sufficient set of marking routines (those not already provided for by another
compilation) and the sufficient set of these are pulled in when the
program is composed. We then use a table to indirect through to find the 
routine to mark a root pointer - all subsequent pointer following can be done 
directly. Only worth it in a predominantly statically typed language of course.

This does up the code size somewhat (depending very much on the mix of types in
your program) and it is very worth making sure that all mark routines are in 
contiguous pages - then there is a bit of a page hit at the beginning and end 
of GC as the program vs the marking routines become live.

----------------------------------------------------------------------
Dave Lloyd                            Email: Dave@occl-cam.demon.co.uk
Oxford and Cambridge Compilers Ltd    Phone: (44) 1223 572074
55 Brampton Rd, Cambridge CB1 3HJ, UK