2) We need a more traditional, non-moving GC as an alternative to the copying collector. A modified mark & sweep'd be fine, but as it'll be living behind the API it doesn't much matter.
This is really only for the chunks of memory backing strings and such, right? We're already using mark-and-sweep for PMCs and strings and such (that is, their headers), right?
As I see it, it's really the allocation that is more complicated with a mark-and-sweep collector (since you have to search for a correct-sized free chunk, efficiently)--the collection itself is the easy part. Actually, it seems like this is just the GC_IS_MALLOC case--that already gives us non-moving GC, and lets malloc (the system version or the Lea version) deal with managing the bookkeeping.
#2 is a bit more interesting and, if we do it right, means that we'll end up with a pluggable garbage collection system and may (possibly) be able to have type 3 threads share object arenas and memory pools, which'd be rather nice. Even if not, it leaves a good window for experimentation in allocation and collection, which isn't bad either.
This, combined with the mention of needing to drive this off of a vtable, means being able to determine the GC algorithm at runtime instead of compile-time (i.e., that was part of your point). I'm all for that--it will mean less #if's in the code, and it will make the code a bit clearer.
JEff
