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

[John R Rose]

On Thu, 2 Oct 2025 07:11:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide to suggest that C++
> Standard Library components may be used, after appropriate vetting and
> discussion, rather than just a blanket "no, don't use it" with a few very
> narrow exceptions. It provides some guidance on that vetting process and
> the criteria to use, along with usage patterns.
> 
> In particular, it proposes that Standard Library headers should not be
> included directly, but instead through HotSpot-provided wrapper headers. This
> gives us a place to document usage, provide workarounds for platform issues in
> a single place, and so on.
> 
> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_traits>`, along with updates to use them. I have a separate change for
> `<new>` that I plan to propose later, under JDK-8369187. There will be
> additional followups for other C compatibility headers besides `<cstddef>`.
> 
> This PR also cleans up some nomenclature issues around forbid vs exclude and
> the like.
> 
> Testing: mach5 tier1-5, GHA sanity tests

I like where this is going.  Thanks for putting in the hard work to make it happen.

doc/hotspot-style.md line 629:

> 627: occur. The C++98/03 `std::allocator` class is too limited to support our
> 628: usage. But changes to the allocator concept in more recent Standards removed
> 629: some of the limitations, supporting statefull allocators. HotSpot may, in the

s/statefull/stateful/

doc/hotspot-style.md line 647:

> 645: using those names easier, since the qualifiers don't need to be included. But
> 646: there are reasons not to do that.
> 647: 

s/reasons/several reasons/ (to better tee up the following bullet list)

doc/hotspot-style.md line 651:

> 649:     headers may be included, adding to the list of names being used. Also,
> 650:     future versions of the Standard Library may add currently unknown names to
> 651:     the headers already being included.

Maybe mention the `assert` macro at the end of the bullet, if there is no other example of a previous name collision:

> …already being included.  (We already have a conflict from the HotSpot `assert` macro, although in that case the `std::` prefix is not applicable.)

doc/hotspot-style.md line 1971:

> 1969: 
> 1970: * `<system_error>`
> 1971: 

To continue the roll of rationale,  for `chrono` etc., here are some suggestions which I am just pulling out of my back pocket:

"HotSpot has its own timing support APIs."
"Initializer lists are an advanced C++ API feature which have surprising interactions with other initialization syntaxes in use in HotSpot."
"HotSpot uses floating point numbers, which are more portable and have more predictable performance characteristics than rational arithmetic."
"HotSpot has its own mechanisms for managing errors."

src/hotspot/share/code/relocInfo.cpp line 29:

> 27: #include "code/nmethod.hpp"
> 28: #include "code/relocInfo.hpp"
> 29: #include "cppstdlib/type_traits.hpp"

(I really, really like this scheme of wrapper headers for std stuff.  Thanks Kim!)

src/hotspot/share/cppstdlib/cstddef.hpp line 34:

> 32: // * std::max_align_t, std::nullptr_t
> 33: // * size_t (preferred) and std::size_t
> 34: // * ptrdiff_t (preferred) and std::ptrdiff_t

Are we 100% sure that `size_t` and `ptrdiff_t` will always be the `std` versions, on all platforms?
If not, uses of `std::size_t` and `std::ptrdiff_t` might turn out to be portability problems.

…Should I worry that `std::size_t` and `size_t` might be different types on some weirdo platform??

Maybe we should do a static-assert that those two names refer to the same type.
Then we can prove that the `std::` prefix will never cause the meaning of `size_t` to shift, on any platform.
I'm being a little paranoid here about possible failure modes specifically for `size_t`,
specifically because `size_t` is so pervasive and sensitive to type bugs.

-------------

Changes requested by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27601#pullrequestreview-3315881937
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414655528
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414658231
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414716232
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414719117
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414738762
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414746409