Well, as I've said elsewhere the immediate-destructs probably comes at a considerable price (compared to the more efficient alternative, not compared to the current implementation). It isn't possible to combine a micro-gc of only the things referenced by the stack and the mark-and-sweep approach - the point with mark-and-sweep is precisely to save the work of continuously tracking the refs to things.
Still, fixing the generational and mark-and-sweep bits would be additional work anyway, so I guess we could start with only the delayed-update refcount gc and dispense with this issue until all the other things start to work a bit. Anyway, I'd like to put more attention on the other serious issue, namely the C module interface compatibility problem. Basically every line that does something like this: THIS->my_thing = some_thing; where some_thing is a pointer to a string, array, or whatever, would have to be changed into some kind of macro/function call: set_ptr (THIS, my_thing, some_thing); This is because the key to be able to do the delayed refcount updates, and to get the on-the-fly gc operation to work, is to intercept every pointer change in the heap and do the logging of the old value that is occasionally required. I can't see any way around that. Thus all existing C modules would be pretty thoroughly hosed until someone goes through them. That hurts, but otoh keeping the current refcount handling would be a very serious problem too.
