RFR: 8369186: HotSpot Style Guide should permit some uses of the C++ Standard Library [v2]

[Kim Barrett]

On Thu, 9 Oct 2025 11:27:26 GMT, Florian Weimer <fweimer at openjdk.org> 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