This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: an idea to speed up GC


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

    Zack> On Sat, Mar 11, 2000 at 04:01:38PM -0800, Mark Mitchell
    Zack> wrote:
    >> >>>>> "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.

    Zack> This surprises me greatly.  When are we going to modify a
    Zack> type, for instance, after it's been created and hashed? 

When, for example, it was incomplete at first, but completed later.
When, in C++, something else declares it as a friend.

    Zack> Or the saved RTL or tree for an inline function?

That is less likely.  It is possible that there are some special cases
that would help here.

However, I doubt the wins are that substantial, relative to other
low-hanging fruit in GCC, some of which probably has considerably less
risk of introducing hard-to-find memory bugs.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]