>>>> The Hermit Hacker wrote:
>> You build the code such that "#ifdef HAVE_ALLOCA" is true, so that those
>> platforms that either don't support it, or have broken suport for it,
>> aren't affect, and you are most welcome to work on it...
alloca is treated as a builtin function by gcc, so it should work on
any platform if you use gcc. If your compiler is not gcc then alloca
is *very* iffy --- as far as I know, it is not specified by any
recognized standard. So I concur with Marc's opinion: a speedup on
alloca-supporting platforms is nice, but it is not acceptable to break
the code on machines without it.
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> As far as I know, alloca is only useful for memory that is used by the
> current function or its children. I don't think we have many cases
> where we could use that.
Right, storage allocated by alloca is part of the calling function's
stack frame --- it goes away when that function exits, no sooner and
no later.
I have noticed some places in Postgres where routines palloc storage
that they pfree before exiting. alloca would be a fine substitute
for that usage. But as far as I've seen in profiling, the primary
callers of palloc are allocating storage that they will *not* free,
but indeed will return to their caller --- the type-specific conversion
routines all work that way, for example. So I'm doubtful that adding
alloca to our tool arsenal would be worth the portability headaches
it would cost.
I have been toying with the notion of nested memory contexts, which
would be created at the start of certain major routines and deleted
when they exit. palloc would allocate storage from the most closely
nested context, and thus would mean "allocate storage that will live
through the current major operation, whatever it is". This is still
a very half-baked notion and I can't say that it will work, but I
thought I'd throw it into the thread...
regards, tom lane
