Related articles |
---|
What's wrong with alloca() ? preston@dawn.cs.rice.edu (1991-12-19) |
Re: What's wrong with alloca() ? apang@mindlink.bc.ca (1991-12-15) |
Re: What's wrong with alloca() ? pardo@cs.washington.edu (1991-12-21) |
Re: What's wrong with alloca() ? preston@dawn.cs.rice.edu (1991-12-22) |
Re: What's wrong with alloca() ? wjw@eb.ele.tue.nl (1991-12-23) |
Re: What's wrong with alloca() ? David.Chase@Eng.Sun.COM (1991-12-23) |
Re: What's wrong with alloca() ? pcg@aber.ac.uk (1991-12-26) |
Re: What's wrong with alloca() ? wicklund@intellistor.com (1991-12-30) |
Re: What's wrong with alloca() ? wws@renaissance.cray.com (1991-12-30) |
Re: What's wrong with alloca() ? jfc@athena.mit.edu (1991-12-31) |
[4 later articles] |
Newsgroups: | comp.compilers |
From: | preston@dawn.cs.rice.edu (Preston Briggs) |
Keywords: | C, storage |
Organization: | Rice University, Houston |
References: | 91-12-075 91-12-079 |
Date: | Sun, 22 Dec 1991 18:08:57 GMT |
pardo@cs.washington.edu (David Keppel) writes:
>By the time you've added these calls you're just
>about all the way to having ``object stack'' allocation, called
>``obstacks'' in GNU terminology. An obstack is an allocation region that
>can be used for incremental allocation and then freed all at once.
I hadn't read of obstacks, but they sound like the "arenas" described in
Fast Allocation and Deallocation of
Memory Based on Object Lifetimes
David R. Hanson
Software - Practice and Experience
January 1990, 20(1)
His implementation is very small and simple. Though allocation costs more
than a single add, it's still very fast (about 8 instructions on a VAX).
Freeing looks like about 4 instructions. It's very handy and I use it a
lot.
However, alloca is still useful. In one example, I use it in a deeply
recursive tree walk, allocating structures of different sizes. We don't
want an arena or obstack, since different pieces become free at different
times (and since it's a tree walk, we'll want to reuse freed chunks from
one branch while walking later branches).
So, we seem to want several sorts of memory allocation, with special case
allocators tuned to the special cases that arise in code. When I said
this to a friend (Scott Warren), he pointed out that we actually want
optimizers that recognize our patterns of usage, and handle the special
cases specially.
Of course, people have worked on this problem.
David Chase is a good example. Are there others?
Preston Briggs
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.