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
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
