[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Use malloca instead alloca

From: Ondřej Bílka
Subject: Re: [PATCH] Use malloca instead alloca
Date: Sat, 29 Dec 2012 20:18:22 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

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
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]