[gclist] Compiler specialized GC's

[boehm.PARC@xerox.com]

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

There are no doubt many implementations that do something along these lines.
SRC M3 is one of them.  The problem is it can easily turn into a pessimization
rather than an optimization.  Bitmap interpretation is fairly cheap and you get
great code locality.  For composite data types, it's also fairly easy to
dynamically generate a fairly flat descriptor for the whole object.  You can
easily avoid recursion with an explicit stack.  Our collector makes no
procedure calls in the mark loop when marking from small objects with (or
without) explicit type information.

In the custom procedure case, there is a significant amount of added code
involved, possibly causing I-cache misses or even paging.  It's tempting to add
more procedure calls for a single contiguous object to share code and possibly
to deal with separate compilation issues.  You can also replace recursion with
an explicit stack, but it complicates the generated code.  (You pretty much
have to do this if you want to recover from running out of memory.)  And there
are likely to be procedure calls involved anyway.

Hans

Standard disclaimer ...