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]
Other format: [Raw text]

Re: Speeding up GC


   From: Andi Kleen <ak@suse.de>
   Date: Tue, 4 Jun 2002 16:52:54 +0200

   > 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?

Do you have another fast way to handle short-term allocations?  I
actually like obstacks more and more the longer I look at the
performance mess have because of GC's introduction.  Going from
3 to 6 hour bootstraps on some SH systems, for example.  That kind of
crap isn't acceptable.

Remember in your answer to my question that the precondition is that
mprotect and the like are not considered fast.  :-)

I am of the opinion that people are in general too lazy about how they
allocate RTL objects when they make changes to the compiler middle and
back ends.  This is why we have this enormous problem today.


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