On Tue, Oct 11, 2022 at 1:06 PM Jonathan Wakely <jwak...@redhat.com> wrote: > > 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?
I was just confused and didn't see you commonized EMERGENCY_OBJ_SIZE already, so ignore my comment. > > 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 >
