[gclist] gc interface

[boehm.PARC@xerox.com]

Re: meta-gc, plug compatible gc's, etc.

Here's a somewhat different opinion on the issue:

- Multiple plug compatible gc's are certainly a good idea, at least in some
cases.  There is a reasonable collection of applications that could benefit
from the null gc which reclaims everything at process exit and nothing before
then.  It's easy to get cheap allocation in this environment.  There are other
applications in which code size is crucial and you want a really simple
algorithm.

- You can carry even the idea of plug-compatible gc's too far.  It's hard to
get rid of the last few bugs in a high performance garbage collector,
especially if there are subtle interactions with the rest of the run-time
system.  It's much harder if you can mix and match gc pieces.  And I believe
you can come up with a single hybrid algorithm that actually does quite well
for nondistributed applications.

- A lot of the choices discussed here do influence the user-visible GC
interface.  If you're building a Lisp system, the foreign function interface
will probably vary depending on whether objects are moved, and whether the
"foreign" stack is traced conservatively for roots, etc.  If the user is
allowed to explicitly trigger a collection, what does that mean with a
generational collector?  With an incremental collector if a collection is
already in progress?  With a collector that primarily uses reference counts?

- Things get much worse if you allow multiple gc's for different program
modules.  Doing this safely, in such a way that you can handle cross module
cycles without performance anomalies is hard.  The only measured performance
improvements I've seen are from systems that sacrifice safety.  As far as I can
tell it gets considerably harder still if you expect to be able to recover from
running out of memory, at least most of the time.  I've seen no reasonable
solution to that problem.  (Even writing mark procedures for our collector is
more of a black art than I would like.  Some of that has to do with the next
point.)

- We all prefer to discuss interesting algorithms rather than ugly
bit-twiddling.  But a lot of the performance of a collector, at least in my
experience, depends on low level implementation details, and constant factors
in the implementation.  Such considerations often outweigh higher level
algorithmic considerations.  It's harder to get these simultaneously right for
a number of interacting implementations.

Hans