Re: [PATCH] libstdc++: Allow emergency EH alloc pool size to be tuned [PR68606]

[Richard Biener <richard.guenther@gmail.com>]

On Tue, Oct 11, 2022 at 1:06 PM Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Tue, 11 Oct 2022 at 07:41, Richard Biener <richard.guenther@gmail.com> wrote:
> >
> > On Mon, Oct 10, 2022 at 5:10 PM Jonathan Wakely <jwakely@redhat.com> wrote:
> > >
> > > On Mon, 10 Oct 2022 at 12:17, Jonathan Wakely <jwakely@redhat.com> wrote:
> > > >
> > > > On Mon, 10 Oct 2022 at 07:18, Richard Biener <richard.guenther@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
>