[gclist] gc interface

[Robert A Duff]

It seems to me from reading various gc papers and this mailing list,
that the performance of various gc techniques is highly dependent on the
properties of the application.  So, one should give some control to the
application programmer, right?  Allow the programmer to pick and choose
different algorithms, tune the various parameters, etc.

Is there any research, or has anybody thought about, how to do this?
Ideally, one would have a well-defined interface between gc, mutator,
and compiler.  And one could plug in different gc algorithms, different
allocators, etc.  And everything would be plug compatible.  Sounds
impossible, since gc is inherently a global issue.

But maybe some subset of that functionality is feasible.  Even within a
single program.  Perhaps part of my program could benefit from a tracing
gc.  Part of it is well-behaved enough to use by-hand freeing, attached
to destructors.  Or maybe even mark/release.  Or ref counting.  Another
part writes data to disk, and needs special consideration.  Some tasks
in my program need hard-real-time response, but some don't.  Some parts
allocate fixed-sized objects, whose size is known at compile time,
whereas some parts allocate run-time sized objects, which are usually
small.  And some parts allocate big objects.

I'm happy to declare what I'm doing, in such a way that the gc can
understand.  I'm not asking for fancy heuristics that work well with
"most" programs, but some way to tune things to my particular needs.

Maybe part of my program involves distribution.  Well, distributed gc is
far from a "solved problem", so I'd like to say, fine, I'll handle the
distributed parts by hand, but I still want a local gc.

The key, it seems to me, is to define the interface between the various
pieces, in such a way that the application programmer can pick and
choose pieces.  It's nice if I'm handed a choice of 3 different garbage
collection strategies, and 4 different allocation algorithms I can plug
in (even if there are some contraints, such as allocator 3 doesn't work
with gc 2).  And it's also nice if I can write my own algorithms and
plug them in, too.

I think my idea is essentially the same thing as Francois-Rene Rideau's
"meta gc", but meta-gc sounds more grandiose than just a few interfaces,
where one can plug in different compatible components.  Plug
compatibility also offers the benefit of easy experimentation -- one can
try out different gc's with different applications, to see what works
well in practice.

Any thinking on the issue of mixing and matching parts of gc algorithms?

- Bob