What with threads coming in, some of the limitations of a copying
collector are becoming very apparent. While it's really nice, and
just feels really cool, in the single-threaded case, neither nice nor
cool justifies potentially massive headaches and synchronization
issues when sharing data between interpreters. So, time for some work.

The task is twofold:

1) The garbage collection and memory allocation APIs needs to be
formalized and abstracted a bit. (We're likely most of the way there,
but it's been a while since I've looked and, honestly, the GC/DOD
system's seen some pretty major upheavals since then) It also needs
to live in a vtable of sorts that can hang off the interpreter, so we
can swap it out as need be.

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.

#1 is a bit of code digging and gruntwork combined with a bit of
thought (if the API needs formalizing) and can be done even if you've
no clue what's going on in the GC or DOD.

#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.
--
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk