On Tue, 11 Oct 2022 at 07:41, Richard Biener <richard.guent...@gmail.com> wrote: > > On Mon, Oct 10, 2022 at 5:10 PM Jonathan Wakely <jwak...@redhat.com> wrote: > > > > 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. > > So can we then commonize some of the #defines by using sizeof(void *) > (taking pointer size as word size?)
What did you have in mind? Do you mean use sizeof(void*) instead of the SIZEOF macro? MAX_OBJ_COUNT uses the SIZEOF macro so it can be used in a preprocessor condition: #ifdef _GLIBCXX_EH_POOL_NOBJS # if _GLIBCXX_EH_POOL_NOBJS > MAX_OBJ_COUNT
