alloca wars

[David Keppel]

>[ When is it hard to do alloca? ]

The fast (compiler-supported) alloca may turn off other optmizations.
It need only turn them off in the function using alloca and (given
that memory management is often expensive) you aren't likely to lose a
whole lot by using alloca.

The slower (library-supported) alloca will break whenever you have a
multi-thread (e.g., lightweight process) program (at least in every
"reasonable" implementation that I've thought of).  This may be a
problem for shared-memory multiprocessors.

During the last alloca war somebody suggested having alloca require
explicit "free" semantics, so that malloc-based (library) allocations
would be reasonable to write and work on shared-memory multiprocesors.
This would probably also hose fewer compilers/architectures.  If I
understand, code would look like:

	:
	foo = alloca( size );
	:
	afree( size );
	return( value );

This complicates the code slightly, but (I believe) would give
everybody "the best of both worlds".  Does anybody object to these
semantics?

Note that GNU products are *not* designed to work on every machine.
The documentation for gcc (as I remember) says that it is designed to
work with 32-bit machines with a flat (non-segment-register) address
space.  Alloca could be seen as a constraint on this.  Finally, gcc
makes some extensions that can destroy alloca semantics; garbage
collection can (silently) take place before the end of the function,
so even their use is broke (and is documented as such).

[ Please, he said following up, try to keep down your
  followup-rate.  We just got done with this war a few weeks ago ]

	    ;-D on  ( What, me deallocate? )  Pardo

		    pardo at cs.washington.edu
    {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo