I'm only speculating here, but: Yes, I believe that Perl can make more efficient use of GC than Lisp does. You can't swing a dead cat in a Lisp program without allocating and freeing scads of conses. Perl, being written in C or something equally capable of low-level manipulation, can avoid hot spots in GC as they are measured.

Based on lurking around the gcc mailing lists, I think the reason the conservative GC can *be* conservative is that it's given a relatively small number of "root pointers" that are the only valid sources for reference chains of GC'able objects. If you miss a root pointer, you get memory corruption. But I'd rather do that than count references.

But as for the GC library itself: If we use the Boehm GC library, which is somewhere between version 5 and version 6... NO, I don't expect that the GC mechanism will have any bugs, at least none worth speaking of. It's been put through the wringer too many times.

No, destruction order is not maintained. But we've already figured out that we want to separate end-of-scope cleanup per se from object descruction. I wouldn't be surprised to see Perl go the way of Java and not even have any actual descructors. (I hope I'm not misstating how Java works....)

Actually, the gcc example is a good one. They've converted an existing program from non-GC to GC and they're happy with the results.... How much better off will we be if we design Perl 6 to use GC from day one?

    -- Chip Salzenberg, Free-Floating Agent of Chaos