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

[Jonathan Wakely <jwakely at redhat dot com>]

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.

> > With the cost of some more members I can make the allocator more
> > generic (use a constructor with a arena and a arena size parameter)
> > and we may move it somewhere public under __gnu_cxx?  But eventually
> > boost has something like this anyway.
>
> Didn't explore this - it doesn't really match the STL allocator interface
> and imposes overhead even over an implementation class (STL allocators
> know the size of the objects they free).

Yeah, I don't think there's any advantage complicating this type to
make it usable as an STL allocator - it does what it's designed to do
and that's fine.

> I'm re-bootstrapping / testing with the cosmetic changes I did and
> with EH allocation not forced to go through the emergency pool
> (I've done that in previous bootstraps / tests to get the pool code
> exercised).

> Any comments?  We have a customer that runs into the issue that 64
> bad_alloc exceptions are not enough for them (yes, they require bad_alloc
> to work when thrown in a massive quantity from threads).  Other
> solutions for this would include to simply wait and re-try (with possibly
> deadlocking if no progress is made) to artificially throttling
> bad_alloc allocations from the EH emergency pool (identify it by
> size, sleep some time inside the lock).
>
> CCing rth who implemented the existing code.

I don't have any better ideas for fixing the issue, so it's approved
by me. Unless rth comes back with something else please go ahead and
check it in.