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

[Stefan Karlsson]

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_info>`, 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 1658:

> 1656: to anonymous heterogeneous sequences.  In particular, a standard-layout
> 1657: class is preferred to a tuple.
> 1658: 

I gave this feedback offline, but I'll record it here as well. I think that the tuple section should go to the undecided section.

I understand the wish to go with named classes, and I often prefer that as well, but I also see that people often refrain from doing using them various reasons and instead use out-parameters or mix return values into one primitive. I don't want to fully close the door on this feature, and would like us to put this in the undecided (yes, still implicitly forbidden) section. To me that signals that we can at least experiment with it to see if it makes sense to sometimes use it (and if it does we can bring that back for discussion). Whereas outright forbidding it puts a stake in the ground and tells the story that we really shouldn't be looking at tuples. I think that's a too strong of a statement.

src/hotspot/share/utilities/tuple.hpp line 2:

> 1: /*
> 2: * Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved.

So we have our own tuple ...

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

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