On Thu, 9 Oct 2025 11:27:26 GMT, Florian Weimer <[email protected]> wrote:
>> Kim Barrett has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - jrose comments >> - move tuple to undecided category > > doc/hotspot-style.md line 567: > >> 565: >> 566: Functions that may throw exceptions must not be used. This is in >> accordance >> 567: with the HotSpot policy of [not using exceptions](#error-handling). > > In the GCC implementation, destructor registration may throw > `__gnu_cxx::recursive_init_error` (via the `__cxa_guard_acquire` Itanium ABI > function). Are global or static objects with non-trivial destructors > permitted? I think there are a couple of such uses today. We (you and me, @fweimer-rh) discussed this a couple of years ago: https://mail.openjdk.org/pipermail/hotspot-dev/2023-December/082324.html Quoting from here: https://mail.openjdk.org/pipermail/hotspot-dev/2023-December/083142.html " Empirically, a recursive initialization attempt doesn't make any attempt to throw. Rather, it blocks forever waiting for a futex signal from a thread that succeeds in the initialization. Which of course will never come. And that makes sense, now that I've looked at the code. In __cxa_guard_acquire, with _GLIBCXX_USE_FUTEX, if the guard indicates initialization hasn't yet been completed, then it goes into a while loop. This while loop tries to claim initialization. Failing that, it checks whether initialization is complete. Failing that, it does a SYS_futex syscall, waiting for some other thread to perform the initialization. There's nothing there to check for recursion. throw_recursive_init_exception is only called if single-threaded (either by configuration or at runtime). " It doesn't look like there have been any relevant changes in that area since then. So I think there is still not a problem here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2416593903
