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

[Jonathan Wakely]

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.