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.
