Re: [PATCH] Use malloca instead alloca

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Jan 09, 2013 at 05:09:23PM +0100, Florian Weimer wrote:
> On 01/08/2013 09:41 PM, OndÅej BÃlka wrote:
> 
> >One technical issue is if we want to use STACKINFO_BP_DEF. It would make
> >getting base pointer more portable but must be added to each function
> >that uses __libc_use_alloca.
> 
> I'm interested in extending GCC to provide a better alloca,
> including one that can fail.  Parts of the split stacks support
> might reusable for obtaining the stack boundary.

We spent a bit of time analyzing whether split stack is useful on the
musl list, and concluded that for the most part it's just harmful. For
64-bit systems, it has no significant advantages over just allocating
large stacks and letting the kernel do overcommit. For 32-bit systems,
you risk overcommitting virtual address space and crashing when your
threads run out of stack because they can't map more, but there are of
course some usage patterns on 32-bit systems where they may make it
possible to do things that would otherwise not be possible without
delicate analysis of stack needs and manual use of thread stack-size
attributes.

Overall, it seems to be an overcomplicated, mostly-harmful feature.

> I'm a bit skeptical about the whole alloca-if-we-have-room concept.
> We must make sure that we keep sufficient stack space for further
> operation.  But I'm not sure how to determine the magic number of
> bytes to reserve.

I agree entirely. It strikes me as just as misguided as when
application developers ask "how to I check how much memory the system
has so I can hoarde it all?" If you're making what you use
proportional to what's available rather than to what you need, you're
doing something wrong.

Honestly, my recommendation would be to ban use of alloca and VLA
entirely and replace them by small fixed-size arrays (like 256-1024
bytes depending on the expected usage), and simply call malloc when
the need is greater than the fixed size. This makes the free logic
easy (if (ptr!=fixed_buf) free(ptr);) and reduces the code size and
improves performance in the common cases (since the compiler can
generate better, simpler code when it does not need to do the
frame-pointer-like logic for managing dynamic-size allocations on the
stack.

Rich