On Mon, 10 Oct 2022 at 12:17, Jonathan Wakely <jwak...@redhat.com> wrote: > > On Mon, 10 Oct 2022 at 07:18, Richard Biener <richard.guent...@gmail.com> > wrote: > > > > On Fri, Oct 7, 2022 at 5:55 PM Jonathan Wakely via Gcc-patches > > <gcc-patches@gcc.gnu.org> wrote: > > > > > > This needs a little more documentation (see the TODO in the manual), > > > rather than just the comments in the source. This isn't final, but I > > > think it's the direction I want to take. > > > > > > -- >8 -- > > > > > > Implement a long-standing request to support tuning the size of the > > > emergency buffer for allocating exceptions after malloc fails, or to > > > disable that buffer entirely. > > > > > > It's now possible to disable the dynamic allocation of the buffer and > > > use a fixed-size static buffer, via --enable-libstdcxx-static-eh-pool. > > > This is a built-time choice that is baked into libstdc++ and so affects > > > all code linked against that build of libstdc++. > > > > > > The size of the pool can be set by --with-libstdcxx-eh-pool-obj-count=N > > > which is measured in units of sizeof(void*) not bytes. A given exception > > > type such as std::system_error depends on the target, so giving a size > > > in bytes wouldn't be portable across 16/32/64-bit targets. > > > > > > When libstdc++ is configured to use a dynamic buffer, the size of that > > > buffer can now be tuned at runtime by setting the GLIBCXX_TUNABLES > > > environment variable (c.f. PR libstdc++/88264). The number of exceptions > > > to reserve space for is controlled by the "glibcxx.eh_pool.obj_count" > > > and "glibcxx.eh_pool.obj_size" tunables. The pool will be sized to be > > > able to allocate obj_count exceptions of size obj_size*sizeof(void*) and > > > obj_count "dependent" exceptions rethrown by std::rethrow_exception. > > > > > > With the ability to tune the buffer size, we can reduce the default pool > > > size. Most users never need to throw 1kB exceptions in parallel from > > > hundreds of threads after malloc is OOM. > > > > But does it hurt? Back in time when I reworked the allocator to be less > > wasteful the whole point was to allow more exceptions to be in-flight > > during OOM shutdown of a process with many threads. > > It certainly hurts for small systems, but maybe we can keep the large > allocation for 64-bit targets (currently 73kB) and only reduce it for > 32-bit (19kB) and 16-bit (3kB IIRC) targets.
Maybe this incremental diff would be an improvement: @@ -90,7 +90,7 @@ using namespace __cxxabiv1; // Assume that the number of concurrent exception objects scales with the // processor word size, i.e., 16-bit systems are not likely to have hundreds // of threads all simultaneously throwing on OOM conditions. -# define EMERGENCY_OBJ_COUNT (8 * __SIZEOF_POINTER__) +# define EMERGENCY_OBJ_COUNT (4 * __SIZEOF_POINTER__ * __SIZEOF_POINTER__) # define MAX_OBJ_COUNT (16 << __SIZEOF_POINTER__) #else # define EMERGENCY_OBJ_COUNT 4 This makes it quadratic in the word size, so on 64-bit targets we'd have space for 256 "reasonable size" exceptions (and twice as many single word exceptions like std::bad_alloc), but only 64 on 32-bit targets, and only 16 on 16-bit ones. This slightly increases the initial allocation on x86_64 from 72,704 bytes to 73,728 bytes, but reduces 32-bit from 18,944 bytes to 12,800. If more is needed, it can be chosen via configure or the environment.
