This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Use malloca instead alloca


Thanks for looking into this.  Three comments.

First, as far as correctness goes, one cannot simply replace
{ P = alloca (N); use (*P); } with
{ P = malloca (N); use (*P); freea (P); },
as was done in the examples in
<http://sourceware.org/ml/libc-alpha/2012-12/msg00469.html>.
This is because malloca might return NULL.  Wouldn't you prefer a
different API, where the allocator cannot possibly return NULL
because it reliably aborts if storage is not available?
(This is what gnulib's xmalloca module does.)

Second, if you do want the malloca API, then it seems to me that,
in the typical case, the gnulib implementation should
perform better than the proposed malloca (with _ALLOCA_MC).
The _ALLOCA_MC approach expands to more machine instructions than
the gnulib approach does, which surely hurts instruction caching.
And in the typical case, where alloca is used, the _ALLOCA_MC
version has more work to do (to store _ALLOCA_MC)
than the gnulib code does (no need to store a magic word).
Have you measured the performance of the _ALLOCA_MC approach,
compared to the gnulib approach, on realistic workloads?

Third, the _ALLOCA_MC version mishandles very large sizes, e.g.,
its malloca (SIZE_MAX) goes greatly awry.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]