Re: [PATCH] Use malloca instead alloca

[OndÅej BÃlka <neleai at seznam dot cz>]

On Sat, Dec 29, 2012 at 06:21:55PM -0800, Paul Eggert wrote:
> On 12/29/2012 11:18 AM, OndÅej BÃlka wrote:
> 
> > alloca caused segfault on oom condition and null pointer
> > access has equivalent behaviour.
> 
> alloca doesn't always cause a SEGV on out of memory.
> That's part of the problem that we're trying to cure.
> If alloca is given too large a number, it might SEGV,
> and it might not.  malloca should not have this problem:
> it should reliably fail when out of memory.
> 
> Unfortunately when out of memory the proposed use of
> malloca does not reliably SEGV.  Here's a trivial example:
> 
On my example I checked it causes null access. But you are rigth it
cannot be done in general.
> 
> > And on linux it will always succeed and be killed by oom later.
> 
> Sorry, I'm not following, or perhaps I'm misunderstanding you.
> malloc does not always succeed on GNU/Linux; it sometimes
> returns NULL.  malloc (SIZE_MAX) is a trivial example of this.

It was a example why oom condition cannot be detected reliably.

> 
> > with my implementation is 20% faster than gnulib one.
> 
> First, we need a correct implementation before we can start
> doing benchmark comparisons, as fixing the problems will slow
> things down, I expect.  It's not just the SEGV problem
> mentioned above; it's also the problem with very large
> allocation requests that I mentioned earlier.
OK 
In http://kam.mff.cuni.cz/~ondra/malloca_benchmark.tar.bz2
I changed signal from SEGV to ABRT and sizes. No measurable
performance drop.
> 
> Second, that benchmark invokes malloca on a constant.  But
> actual code rarely does this:
> 
>       char *p = alloca (100);
> 
> as what would be the point?  It's more portable to do this:
> 
>       char buf[100];
>       char *p = buf;
> 
> and one doesn't need either alloca or malloca in this case.
> A more-realistic benchmark would invoke malloca with a
> non-constant, as that's how alloca is typically used in
> practice.
Now passing size by variable and this does not change performance ratio.