Re: alloca vs malloc

[OndÅej BÃlka <neleai at seznam dot cz>]

On Fri, May 16, 2014 at 07:20:20PM -0400, Rich Felker wrote:
> On Sat, May 17, 2014 at 12:56:08AM +0200, OndÅej BÃlka wrote:
> > > > > The cost of a function call to look up the current stack boundaries
> > > > > (or a TLS access to get that info on some archs where TLS access is
> > > > > expensive) defeats much of the purpose of using alloca.
> > > > >
> > > > Oh really? It does not follow malloc also needs tls so you will always
> > > > be faster.
> > > 
> > > If TLS is the dominating factor (think old MIPS where the instruction
> > > to read the TLS register traps and gets emulated by the kernel), it
> > > brings the cost of alloca up on par with malloc, no?
> > >
> > It does but question is if it will be enabled.
> > 
> > > > Also you could avoid that check most times by checking
> > > > request if you crosses page boundary or creating lookup table which page 
> > > > belongs to which tread.
> > > 
> > > Perhaps, but this gets to be a lot more overhead/complexity for little
> > > if any demonstrable gain.
> > >
> > If there is little gain then you do not have to worry about performance
> > degradation in first place.
> 
> Obviously originally there was a performance benefit to alloca. The
> "little demonstrable gain" was referring to the situation where you've
> already made alloca costly (possibly on par with malloc) to deal with
> its other flaws.
>
> > > > > Moreover, turning alloca failures into "reliable crashes" is not a
> > > > > solution. If an operation requires allocation which could fail, it
> > > > > must be able to back out whatever work it already did and report
> > > > > failure. Crashing is not an acceptable implementation.
> > > > > 
> > > > No, when it is third party codebase and it does not want to rewrite
> > > > existing code do you have a better proposal?
> > > 
> > > I was talking about internal usage of alloca in glibc. I don't think
> > > glibc can fix use in third-party software.
> > > 
> > I was not talking about glibc, I was saying how to fix alloca in general.
> > This could make check reliably any alloca in system if you recompile
> > binaries.
> 
> Supposedly GCC already has an option to reliably crash (when expanding
> the stack by more than a page, write at least one byte to each page,
> in order). I have not teasted it heavily though.
> 
Also alternative but I mentioned this as easy consequence of having stack
boundaries. Main aim is to switch for heap allocation when you do not
have enough stack space.

I was not sure if you could do this conversion or not as user could
check that.