an idea to speed up GC

[Mark Mitchell]

>>>>> "Zack" == Zack Weinberg <zack@wolery.cumb.org> writes:

    Zack> Suppose we add a second set of mark bits, call it the frozen
    Zack> set.  You can ask the garbage collector to mark some
    Zack> structure, or all of the roots, and then copy the mark bits
    Zack> to the frozen bits.  Then, instead of clearing all the mark
    Zack> bits at the start of a GC run, we copy the frozen bits to
    Zack> the mark bits.

    Zack> Does this sound worthwhile?

We thought about something similar.  But, the problem is that some of
these things might end up pointing to different things: just because
`a' will always be marked doesn't mean that the things reachable from
`a' will have already been marked.

Something along these lines would work, maybe, but at the risk of
reintroducing hard-to-find memory-has-already-been-freed bugs; the big
win of GC is that we haven't had to debug one of those in ages.

I suspect a bigger win could come from tricks like only marking
NEXT_INSN and never PREV_INSN, and making sure that the GC always
started at the head of a sequence.  As it is now, we run forward over
a sequence, but we keep looking backwards to see if we need to mark
that direction.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com