Plug-In Memory Management

[Matthew Tuck]

I've been thinking and reading a bit about garbage collection recently
after the recent discussion.

I mentioned last night that we should include an incremental and
non-incremental GC.  My rationale was that nonincremental would be
faster because it stopped less often.  Now I've thought of some reasons
why nonincremental and incremental collectors might each be more
efficient than the other - I'm not sure which wins out - I'd have to
talk to the experts - it might well depend on the program and the
collector.  But anyway, that's not the point, it leads to it.

I also remembered that different collectors have different performance,
different restrictions, different worst-case, etc.  That made me ask why
we would attempt to restrict the garbage collectors that could be used. 
Ideally the program could be tested and profiled with all available
collectors to allow best performance.  Of course there would be a
general best-case collector, but like optimisation, you get more out of
it if the put time into it.  Although, assuming you were going to
release with extreme optimisation, doing extreme optimisation for each
GC might be difficult.

So we would have a situation where a programmer could write a GC that
plugs into the compiler.  There would be a specific API for this, and we
could also do it for memory allocators, hopefully orthogonal to the
choice of GC, if possible.

Then we could try to make the GC and MA independent of the target code,
by putting the plug ins over the code generator.  All-in-all, you could
have three orthogonal factors.  I think they should both be possible to
plug-in, at least for a large number of collectors/allocators, but
whether they turn out to be orthogonalisable is another question.

The GC plug-ins would have important information, such as whether they
have specific code generation requirements or are conservative
collectors.  Conservative collectors are not perfect in collecting
everything, but can operate in the absence of object type information,
and may be necessary if we interface with GC-hostile legacy code.

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
                              ***
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/