[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: Sun, 30 Dec 2012 09:22:17 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

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

reply via email to

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