httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@leland.Stanford.EDU>
Subject Re: alloca (was Re: cvs commit: apache-1.3/src/modules/standard mod_log_referer.c)
Date Sun, 24 May 1998 23:58:16 GMT
On Sun, 24 May 1998, Dean Gaudet wrote:

> > My understanding was that one should never use alloca. Not if one expects
> > code to work correctly, or at all.
> Nah, it's safe, it's just not portable.

You're right, of course. I realized this about five seconds after I sent
the email, when I stopped to think about how alloca() would be
implemented. Or at least how I might implement it.

> On traditional systems on which the stack just grows down (or up) from
> some fixed point alloca() is trivial.  The main reason the compiler needs
> to know about it is that it must set up a stack frame to use it.  In
> x86 parlance, the stack frame setup/destruction looks like this:
>     pushl %ebp
>     movl %esp,%ebp
>     subl #-20,%esp	! create a 20 byte stack frame
>     ... rest of the function goes here, and references negative offsets
>     ... from %ebp to access elements of the stack frame

Sounds good. But if the compiler's generated code references stack data
using positive offsets from the stack pointer (%esp? My x86 assembly
knowledge is non-existant; the only assembly I've ever done is SPARC, and
only a few lines of that) instead of negative offsets from the frame
poiner (%ebp, I presume), then alloca() will mess up basically all the
code that follows it, correct? 

>     popl %ebp

> In this context you can (almost) implement alloca just like this:
>     subl #-nnnn,%esp
>     movl %esp,%eax
> Where nnnn is a 4-byte aligned size, and the resulting pointer is %eax.

That sounds right. Assuming that alloca() is implemented inline. If it's a
library function call, it might have to do all sorts of odd things to be
able to manipulate the activation record of the previous stack frame. And
that seems a bit iffy to me, especially if you're mixing code generated by
a multiplicity of compilers with various options on different systems.

Of course, if you're only concerned with gcc on recent revisions of major
systems (as you've said you are), then I guess that isn't a problem.

[description of stack pages on x86-based systems excised]

> palloc() is actually not much more than the above normally... except that
> it incurs a function call overhead.  On non-x86 architectures, it's
> possible that alloca() will cause a function to end up with a stack
> frame it wouldn't otherwise need -- but on x86 almost most functions have
> stack frames because the x86 has so few registers the compiler needs
> somewhere to spill temporaries.

It seems to me that if function call overhead (which is, after all, just a
few machine instructions) is something we need to worry about on a given
architecture, then we should take all the CPUs and squish them, and force
people to buy computers that make sense. Whose bright idea was it to give
the x86 only 16 registers anyway? SPARC has 40. PA-RISC chips have 72. And
those are only the integer ones.

But that has nothing to do with Apache, I guess. Or anything, really.

> Using a large buffer on the stack is about the same performance-wise as
> alloca, except that it gives you fixed lengths for things, and tends to
> make stacks that are far larger than they need to be.  I still haven't
> done the analysis, but I need to figure out what stack depth we achieve
> regularly in apache, because plopping 8k buffers on the stack left and
> right the way we do can chew up a bunch of pages... and there'll be little
> active data on the stack.  This is fine if you've got one process, but
> when every process (thread) needs a dozen extra pages because of this
> sloppiness... well, it adds up.

Good point. Hmm. *shrug*

-- Alexei Kosut <> <>
   Stanford University, Class of 2001 * Apache <> *

View raw message