GC performance - was Re: [gclist] GC topics

[Paul R. Wilson]

I didn't try much to decipher the C code generated from YAFL, but 
here's a concern:  if you're storing all pointer variables on a separate
stack in main memory, they're not going to be register-allocated unless
you're doing something clever I don't know about.  In general, reads
and writes of pointer variables will go through memory.

For RScheme, we do two things to avoid this.

Our abstract machine uses a register model, not a stack model, and we can
put some of our abstract registers in hardware registers with some compilers
(e.g., the GNU C compiler).  So with a little per-platform fiddling of a
header file, we can get some real registers to use for the most important
ones.  (But SPARCs and Intel x86's are a pain because of an awkward shortage
of plain old global registers.)  Of course, this is not portable.  We
can generate portable C, but it's a bit slower.

The other trick---which is portable---is to compile Scheme expressions
into C expressions, so that the intermediate values (temporaries) of
those expressions can be register-allocated by the C compiler in the
usual way.  For this, we rely on the fact that we only GC at safe
points, and C expressions never cross safe points.  (That takes a little
work in the compiler, but not much---we just don't glom things together
into C expressions if they include a safe point.)

All of this should let us generate decent code while supporting full
fine-grained continuation capture, copying GC, fine-grained pointer
swizzling, etc.  Right now, other aspects of the compiler need to be
improved before we can really tell how well this strategy works---we're
generating mediocre code, but mostly for other reasons.  Ultimately, I
think it will cost us significantly, but not prohibitively, relative
to generating C in the usual way and relying on conservative GC.  (For
some criterion of "significantly" and "prohibitively", to be reverse
engineered to fit the eventual results. :-)