Re: [PATCH] Fix PR64535 - increase emergency EH buffers via a new allocator

[Richard Biener <rguenther at suse dot de>]

On Tue, 20 Jan 2015, Jonathan Wakely wrote:

> On 20/01/15 10:06 +0100, Richard Biener wrote:
> > On Mon, 19 Jan 2015, Jonathan Wakely wrote:
> > 
> > > On 19/01/15 11:33 +0100, Richard Biener wrote:
> > > > On Mon, 12 Jan 2015, Richard Biener wrote:
> > > >
> > > > >
> > > > > This "fixes" PR64535 by changing the fixed object size emergency pool
> > > > > to a variable EH object size (but fixed arena size) allocator.  Via
> > > > > combining the dependent and non-dependent EH arenas this should allow
> > > > > around 600 bad_alloc throws in OOM situations on x86_64-linux
> > > > > compared to the current 64 which should provide some headroom to
> > > > > the poor souls using EH to communicate OOM in a heavily threaded
> > > > > enviroment.
> > > > >
> > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu (with the #if 1
> > > > > as in the patch below, forcing the use of the allocator).
> > > 
> > > I see only the #else part is kept now - that was what I was going to
> > > suggest.
> > > 
> > > > Unfortunately I couldn't get an answer of whether throwing
> > > > bad_alloc from a throw where we can't allocate an exception
> > > > is a) valid or b) even required by the standard ('throw' isn't
> > > > listed as 'allocation function' - also our EH allocators are
> > > > marked as throw(), so such change would change the ABI...).
> > > 
> > > I'll ask the C++ committee.
> > 
> > Thanks.  Only needing to deal with std::bad_alloc allocations from
> > the pool would greatly simplify it (I'd do a fixed-object-size one then).
> 
> Basically the unspecified way memory is allocated for exceptions
> cannot be 'operator new()', but malloc or a static buffer (or both) is
> OK. If that runs out of space (which is the situation we care about
> here) it's undefined, because the program has exceeded the system's
> resource limits. So we can do whatever is best for our users.
> 
> On that basis, I think using a fixed-object-size pool and only using
> it for bad_alloc exceptions is reasonable.

Though my question was whether 'throw X()' might instead behave as
'throw std::bad_alloc()' if allocating X exceeds the system's resource
limits.  I guess the answer is yes as it's undefined?

Of course we can't really implement that because our EH allocator
is marked throw().

Richard.