On Thu, 9 Oct 2025 12:16:11 GMT, Kim Barrett <[email protected]> wrote:
>> 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. @kimbarrett Sorry, I forgot about the old thread. You can get the exception in a single-threaded scenario, something like this: struct S { S() { static S s; *this = s; } } global; Maybe the actual rule is more like this? > Functions that may throw exceptions must not be used, unless individual calls > ensure that these particular invocations cannot throw exceptions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2464779655
