Message ID | 20140516225608.GA17863@domone.podge |
---|---|
State | New |
Headers | show |
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. Rich
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.
diff --git a/stdlib/alloca.h b/stdlib/alloca.h index 2d592d4..255af45 100644 --- a/stdlib/alloca.h +++ b/stdlib/alloca.h @@ -32,7 +32,7 @@ __BEGIN_DECLS extern void *alloca (size_t __size) __THROW; #ifdef __GNUC__ -# define alloca(size) __builtin_alloca (size) +# define alloca(size) (VERIFY_ALLOCA (size) ? __builtin_alloca (size) : (abort, NULL)) #endif /* GCC. */ __END_DECLS