This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Use malloca instead alloca
On Wed, Jan 09, 2013 at 12:43:30PM -0500, Rich Felker wrote:
> On Wed, Jan 09, 2013 at 05:59:45PM +0100, Florian Weimer wrote:
> > Anyway, to clarify, I'm not interested in enabling split stacks per
> > se. But the split stack support records the stack boundary in a TLS
> > variable, and __builtin_alloca could use that to check (reasonably
>
> OK, that makes sense. I still don't think it's useful however because
> the "use as much as we have available" idiom is broken.
>
> > >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.
> >
Where do you want to place these arrays?
Global? You cannot do it due race conditions.
Thread local? You cannot do it in recursive functions.
Also signal handlers break this.
Performance is also worse due of extra indirection.
On stack? In better case gcc will translate free check into
comparison with frame pointer.
In worse case it won't and you have increased register
pressure. This makes code slower.
Also with recursive functions you allocate more stack that
is needed.
> > As long as there's alloca, developers will use it. It's quite
> > popular even in new code.
>
> Application developers can use it, but a particular project libc glibc
> can impose a policy that it's not allowed in that project's code.
>
> > I suspect it's not just the performance
> > aspect, the implicit free() is likely a factor, too.
>
> Implicit free does not help if you have to have an alternate case for
> using malloc on large allocations. And performance is worse than the
> fixed-size automatic array approach I described due to frame pointer
> management.
See above
>
> > I'm not sure if we can change this preference, at least until we
> > have conservative garbage collection as part of libc (so that heap
> > allocation and stack allocation are equally simple).
>
> Conservative GC is not the solution for that. If you're talking about
> libc-internal memory usage, the simplest/cleanest solution would be
> something like talloc where a single cleanup call before returning
> from libc to the caller can free either (1) all memory allocated as
> part of the work in libc-space, or (2) only temp working memory
> that was allocated. This would make both success and error returns
> trivial to handle.
>
As you mentioned GC then determining when it is possible to allocate on
stack and do it is hot topic. It make GC faster, with smaller memory
footprint, more cache friendly etc as he does not to consider objects on
stack. So you cannot avoid solving this question.
> All conservative GC would do is add lots of complexity and vulns where
> memory fails to be freed under attacker-controlled conditions.
>
> Rich