This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Speeding up GC
- From: Joe Buck <Joe dot Buck at synopsys dot com>
- To: ak at suse dot de (Andi Kleen)
- Cc: davem at redhat dot com (David S. Miller), dberlin at dberlin dot org,pkoning at equallogic dot com, levon at movementarian dot org, ak at suse dot de,rth at redhat dot com, gcc at gcc dot gnu dot org
- Date: Tue, 4 Jun 2002 09:18:50 -0700 (PDT)
- Subject: Re: Speeding up GC
> > This is kind of the "next level" of what I was proposing. Once you
> > have this "enter short-term mode" thing, you can have the "exit
> > short-term" call just reset the state of all the temporary GC pools as
> > if GC has been run on them and no references had been found.
>
> Just doesn't this bring all the bugs back that got fixed by the GC introduction?
You make the short-term area just a pool of the GC, and you have two
modes, settable by a flag. In the production mode, when "exit short-term"
is called you just nuke the short-term pool. In the GC-debug mode, when
exit short-term is called you do a GC and abort if there's anything live
in the short-term pool. You then run the full regression suite in the
GC-debug mode. GC-debug is shipped, so that if any user gets a mysterious
ICE you can see if this is the cause.