[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #9 from Eric Gallager <egallager at gcc dot gnu.org> ---
This came up on the mailing lists; see the "performance of exception handling"
/ "size of exception handling" thread in this month's archive of the gcc
mailing list (I forget the exact message)

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[dumoulin.thibaut at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606

Thibaut M. <dumoulin.thibaut at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dumoulin.thibaut at gmail dot com

--- Comment #10 from Thibaut M. <dumoulin.thibaut at gmail dot com> ---
I understand the patch
https://gcc.gnu.org/legacy-ml/gcc-patches/2016-12/msg01158.html has not been
applied.

The dynamic constructor of global variable `pool emergency_pool;` in
`libstdc++-v3/libsupc++/eh_alloc.cc` remains and is still allocating
unconditionally at least 2.5ko on the heap.

> see the "performance of exception handling" / "size of exception handling"
> thread in this month's archive of the gcc mailing list
I was not able to find the thread about "exception handling" of 2020-05, could
you point it out or detail the conclusion please?

Has a solution been found for embedded systems with very limited resources? In
this case for example, C++ exceptions can be disabled and this emergency pool
not needed.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[rdiezmail-gcc at yahoo dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606

--- Comment #11 from R. Diez <rdiezmail-gcc at yahoo dot de> ---

> Has a solution been found for embedded systems with very limited resources?
> In this case for example, C++ exceptions can be disabled and this
> emergency pool not needed.

Contrary to popular belief, C++ exception handling does not need many
resources. I have been generating dynamic error messages in readable English
using C++ exceptions on microcontrollers with as little as 16 KiB SRAM for
years, with 'plenty' of memory to spare.

To that effect, I have been using the patch that I mentioned above. Here is an
updated URL for it:

https://github.com/rdiez/JtagDue/blob/master/Toolchain/Patches/GccDisableCppExceptionEmergencyBuffer-GCC-5.3.0.patch

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[dumoulin.thibaut at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606

--- Comment #12 from Thibaut M. <dumoulin.thibaut at gmail dot com> ---
Thank you for the updated link!

The problem with the original code is that it malloc unconditionally at least
2.4ko on the heap. This cannot be avoided when liking with libstdc++.
This malloc is done very early, when initializing `.init_array` section (in
ResetHandler on an ARM Cortex M for example).

As 2.4ko is a lot for some embedded systems, it would be nice to avoid this
behavior.
Also, even if this code is never used in your project, none of the symbols in
eh_malloc.cc are called; the constructor of the global variable `pool
emergency_pool;` calls a non-pure functions, compiler cannot get rid of this
function.

If you do not use this code in your project, it will cost you, unconditionally,
2.4ko of heap.
This is the problem.

This patch https://gcc.gnu.org/legacy-ml/gcc-patches/2016-12/msg01158.html
seems a nice solution, it allocates a static buffer and if nobody is using it,
it can be stripped by the linker.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[rdiezmail-gcc at yahoo dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606

--- Comment #13 from R. Diez <rdiezmail-gcc at yahoo dot de> ---
It is hard to automatically tell whether nobody else is using such a
statically-allocated emergency buffer. In my case, I am using C++ exceptions,
so the linker will probably always include the buffer.

My patch makes sure that no emergency buffer is allocated. As long as your
firmware does not run out of malloc RAM, C++ exceptions continue to work fine.

About implementing a proper solution (my patch is just a workaround): There are
probably guys who want to control the size of the emergency buffer, but for
really constrained environments, I would like an option to disable it
completely.

As a bonus, the code that allocates and uses the emergency buffer could be
optimised away too, but that is not critical for me. RAM / SRAM is often tight,
but Flash/program memory (where the code resides) tends to be much bigger. So
optimising the buffer away from RAM would be enough in most scenarios.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to R. Diez from comment #13)
> About implementing a proper solution (my patch is just a workaround): There
> are probably guys who want to control the size of the emergency buffer, but
> for really constrained environments, I would like an option to disable it
> completely.

Yeah, tunable size would be good to do as part of PR 88264, but having a
build-time configuration to disable it completely is also valuable. And we can
do that more easily.

Let's try to do that for GCC 13.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Thibaut M. from comment #10)
> > see the "performance of exception handling" / "size of exception handling"
> > thread in this month's archive of the gcc mailing list
> I was not able to find the thread about "exception handling" of 2020-05,
> could you point it out or detail the conclusion please?

This thread:
https://gcc.gnu.org/pipermail/gcc/2020-May/thread.html#232358

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #14)
> (In reply to R. Diez from comment #13)
> > About implementing a proper solution (my patch is just a workaround): There
> > are probably guys who want to control the size of the emergency buffer, but
> > for really constrained environments, I would like an option to disable it
> > completely.
> 
> Yeah, tunable size would be good to do as part of PR 88264, but having a
> build-time configuration to disable it completely is also valuable. And we
> can do that more easily.
> 
> Let's try to do that for GCC 13.

Any such solution would also be OK to backport I think.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #16)
> Any such solution would also be OK to backport I think.

Yeah, it would have no effect unless you explicitly enable the new option.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[dumoulin.thibaut at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606

--- Comment #18 from Thibaut M. <dumoulin.thibaut at gmail dot com> ---
Jonathan, it looks like you have a good idea of what could be the patch, could
you detail it please? :) Or are you referring to the one you already suggested
here https://gcc.gnu.org/legacy-ml/gcc-patches/2016-12/msg01158.html ?

Thanks for pointing out the thread about exception optimization, very
instructive.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606

--- Comment #19 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Dunno yet, I need to remind myself what that old patch did, and decide if it's
the right approach. I'm busy with other things for now so haven't looked at it
yet.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606

--- Comment #20 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603073.html

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:637e3668fdc17c4e226538fb14f9fab225433d01

commit r13-3234-g637e3668fdc17c4e226538fb14f9fab225433d01
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Oct 5 21:21:54 2022 +0100

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

    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 on 32-bit and 16-bit targets. Most users never need to throw 1kB
    exceptions in parallel from hundreds of threads after malloc is OOM. The
    users who do need that can use the tunables to select larger sizes.

    The old defaults can be chosen at runtime by setting GLIBCXX_TUNABLES
    to:
    64-bit: glibcxx.eh_pool.obj_count=64:glibcxx.eh_pool.obj_size=112
    32-bit: glibcxx.eh_pool.obj_count=32:glibcxx.eh_pool.obj_size=104

    Or approximated by configuring with:
    64-bit: --with-libstdcxx-eh-pool-obj-count=252
    32-bit: --with-libstdcxx-eh-pool-obj-count=94

    libstdc++-v3/ChangeLog:

            PR libstdc++/68606
            * Makefile.in: Regenerate.
            * acinclude.m4 (GLIBCXX_EMERGENCY_EH_ALLOC): New macro.
            * configure: Regenerate.
            * configure.ac: Use GLIBCXX_EMERGENCY_EH_ALLOC.
            * crossconfig.m4: Check for secure_getenv.
            * doc/Makefile.in: Regenerate.
            * doc/xml/manual/configure.xml: Document new configure options.
            * doc/xml/manual/evolution.xml: Document addition of tunables.
            * doc/xml/manual/using_exceptions.xml: Document emergency
            buffer and tunables.
            * doc/html/*: Regenerate.
            * include/Makefile.in: Regenerate.
            * libsupc++/Makefile.am: Use EH_POOL_FLAGS.
            * libsupc++/Makefile.in: Regenerate.
            * libsupc++/eh_alloc.cc (EMERGENCY_OBJ_SIZE): Define in units
            of sizeof(void*) not including the ABI's exception header.
            (EMERGENCY_OBJ_COUNT): Define as target-independent calculation
            based on word size.
            (MAX_OBJ_COUNT): Define macro for upper limit on pool size.
            (pool) [_GLIBCXX_EH_POOL_STATIC]: Use fixed-size buffer.
            (pool::buffer_size_in_bytes): New static member function.
            (pool::pool): Parse GLIBCXX_TUNABLES environment variable to set
            pool size at runtime.
            (pool::in_pool): Use std::less<void*> for total order.
            (__freeres) [_GLIBCXX_EH_POOL_STATIC]: Do nothing.
            (__cxa_free_exception, __cxa_free_dependent_exception): Add
            [[unlikely]] attributes.
            * po/Makefile.in: Regenerate.
            * python/Makefile.in: Regenerate.
            * src/Makefile.in: Regenerate.
            * src/c++11/Makefile.in: Regenerate.
            * src/c++17/Makefile.in: Regenerate.
            * src/c++20/Makefile.in: Regenerate.
            * src/c++98/Makefile.in: Regenerate.
            * src/filesystem/Makefile.in: Regenerate.
            * src/libbacktrace/Makefile.in: Regenerate.
            * testsuite/Makefile.in: Regenerate.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #22 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for GCC 13