Re: What's wrong with alloca() ?

preston@dawn.cs.rice.edu (Preston Briggs)
Sun, 22 Dec 1991 18:08:57 GMT

          From comp.compilers

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]
| List of all articles for this month |

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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.