On Sat, Dec 29, 2012 at 09:38:04AM -0800, Paul Eggert wrote:
> 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.)
Here I can as alloca caused segfault on oom condition and null pointer
access has equivalent behaviour.
And on linux it will always succeed and be killed by oom later.
>
> 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?
Of course. In this benchmark
http://kam.mff.cuni.cz/~ondra/malloca_benchmark.tar.bz2
with my implementation is 20% faster than gnulib one.
>
> Third, the _ALLOCA_MC version mishandles very large sizes, e.g.,
> its malloca (SIZE_MAX) goes greatly awry.
--
CD-ROM server needs recalibration
