</lurk>
I have been enjoying the recent discussion of GC vs refcounting. Thanks.
While you're rehashing/justifying sensible design decisions made years ago ;-) I was wondering why you decided to roll-your-own GC rather than use an established one e.g. Hans Boehm's.
I did look at the Boehm collector when we started this. It's a good piece of software and works really well. The reason I didn't go with it was basically one of speed.
The Boehm collector is a conservative collector -- that is, it doesn't make any assumptions about what is and isn't a pointer to a collectable thing, and errs on the side of caution. For the uses people put it to, that's a good thing indeed. That caution brings two issues along with it, though. The first is that it's relatively slow, since it can't make any assumptions about what is and isn't a pointer, and therefore has to treat everything as if it might be a pointer and test it accordingly. The second issue is that since it can't assume things really are pointers or not you can have random memory mis-identified as a pointer to something and therefore have an object left as live when it really isn't. Neither of these problems is a bug per se in the Boehm collector -- it's one of those nature of the beast things.
Parrot, though, because of what it is doesn't need a conservative collector. We can know exactly where pointers to collectable things live, which means that we can both be faster (no pointer tests, no spending time on memory that can't be pointers) and exact. That means collection runs don't leave objects alive when they're not because an IEEE float or bitvector was mis-identified as pointing to something real, and it means that collection runs are faster since we check fewer places for pointers, the pointer checks are faster (no checking to see if it's a real pointer), and there are on average fewer objects alive at any one time. The only place this falls down is when we check the system stack, but it's generally only a few dozen words, so the extra overhead's OK, and it certainly beats the alternative. (Which is crashing)
Basically if you're in a position to build an exact collector you'll get a nice speed win over using a conservative one. If you can reduce the uncertainty you get a speed boost. A lot of programs aren't in a position to do that, which is fine. Parrot, because of what it is, *is* in a position to do so, so we did.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
