[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #18396] stack size setrlimit call interacts badly with Solaris/
Re: [bug #18396] stack size setrlimit call interacts badly with Solaris/x86 kernel bug
Wed, 29 Nov 2006 09:41:10 -0500
On Wed, 2006-11-29 at 13:22 +0000, Jon Grant wrote:
> > Finally, there is no way to detect an out of stack error and exit gracefully
> > with a warning as you suggest: the behavior of alloca() is undefined if you
> > run out of stack space (it doesn't just return NULL as malloc() etc. do).
> Is it undefined in actuality though? Has anyone checked if NULL does get
> returned from any implementations?
>From the standpoint of GNU make it doesn't matter all that much what
some implementations do. In order to be portable it must assume the
lowest common denominator.
> My view would be that on modern computers switching to allocate from the
> heap wouldn't make a big difference if it were changed. Modern heaps
> have pools for small allocations to stop them fragmenting larger
> allocations anyway. Someone would need to do a compressive test to know
> for sure, these things often have knock on effects.. I've seen massive
> slowdowns when someone switched malloc() to calloc() on MS-Windows!
Well, yes, but changing from malloc() to calloc() actually has a
significant difference: in the latter all the memory you've allocated
needs to be zeroed out. That can have all kinds of implications even
beyond the obvious need to walk all the bytes in each allocation, in
terms of swapping, cache issues, etc.