On Wed, 8 Oct 2025 18:40:01 GMT, John R Rose <[email protected]> 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
