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

[Kim Barrett]

On Wed, 8 Oct 2025 18:40:01 GMT, John R Rose <jrose 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
>
> 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."

I'll add some stuff to the PR change.

> "HotSpot has its own timing support APIs."

The argument for chrono is that our existing APIs aren't serving us well.
chrono provides strong type safety. We've had multiple cases of mistakes like
a double seconds being treated as double millis or vice versa, and other
similar errors. But it would be a large effort to adopt chrono. And we'd need
to decide whether to use the predefined clocks or hook up chrono to our
clocks. It may be that using the predefined clocks is fine, but it's a
question that needs careful study.

> "Initializer lists are an advanced C++ API feature which have surprising
> interactions with other initialization syntaxes in use in HotSpot."

I think the trailing "in use in HotSpot" can be dropped from that. Mostly I
think they are fine, but the potential ambiguity between some forms of direct
initialization and initializer list initialization, and the resolution of that
ambiguity, is unfortunate.

> "HotSpot uses floating point numbers ..."

Note that `<ratio>` is a *compile-time* rational arithmetic package. It's also
fixed (though parameterized) precision. It's not a general purpose rational
arithmetic facility. My understanding is that it started life as a detail of
chrono, and was extracted and promoted to a public facility in the belief that
it has broader utility.

> "HotSpot has its own mechanisms for managing errors."

Well, no, we don't really. Or rather, we've got a plethora of bespoke ad hoc
mechanisms. There's a bunch of discussion happening around that topic lately.
I don't think we've coalesced around any particular approach yet. And even
once we decided on something it's likely to take quite a while for rollout to
really make use of whatever we settle on.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2415447980