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: 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.

Heh.

  garbage collection (gär'bij kolek'shon)
	noun.

	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.

		Linus


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