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

[Jonathan Wakely <jwakely at redhat dot com>]

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.