This is the mail archive of the
mailing list for the GCC project.
Re: Faster compilation speed
- From: Linus Torvalds <torvalds at transmeta dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 10 Aug 2002 10:41:34 -0700 (PDT)
- Subject: Re: Faster compilation speed
On Sat, 10 Aug 2002, Richard Kenner wrote:
> Bad example. That code predates any sort of GC and has to do with
> *correctness* issues involving the semantics of RTL, not anything having
> to do with allocation efficiency.
garbage collection (gär'bij kolek'shon)
The act of not managing your memory explicitly, but trusting
some other power to free the memory after you're done with it.
See also: lazy bum, religion, trust in higher powers, flame wars
gcc has always depended on garbage collection, it's just that it generated
the garbage, and the OS collected it when it exited.
The obstacks _are_ a real memory management technique, but obstacks are
clearly broken. The ordering constraints are too tight to be useful for
most real life situations, which means that when you rely exclusively on
obstacks you end up usually not freeing that obstack at all, until your
whole phase is done (very few problems are _so_ clearly nested that a
stack is a sufficient memory management technique).
Or am I wrong?
Basically, what I'm saying is that it _does_ have everything to do with
allocation efficiency. The gcc allocators have just always been bad.