RFR: 8282668: HotSpot Style Guide should permit unrestricted unions

[Daniel D.Daugherty]

On Fri, 4 Mar 2022 18:39:33 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to permit the use of "unrestricted unions"
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf) in HotSpot
> code.
> 
> This permits any non-reference type to be used as a union data member, as well
> as permitting static data members in named unions. There are various classes
> in HotSpot that might be able to take advantage of this new feature.
> 
> An example is the aarch64-specific Address class. It presently contains a
> collection of data members. For any given instance, only some of these data
> members are initialized and used. The `_mode` member indicates which. So it's
> effectively a kind of discriminated union with the data unpacked and not
> overlapping, with `_mode` being the discrimenant. A consequence of the current
> implementation is that some compilers may generate warnings under some
> circumstances because of uninitialized data members. (I ran into this problem
> with gcc when making an otherwise unrelated change to one of the member
> types.) This Address class could be made smaller (so cheaper to copy, which
> happens often as Address objects are frequently passed by value) and usage
> made clearer, by making it an actual union. But that isn't possible with the
> C++03 restrictions.
> 
> Another example is the RelocationHolder class, which is effectively a union
> over the various concrete Relocation types, but implemented in a way that
> has some issues (JDK-8160404).
> 
> Testing:
> I've tried some examples without running into any problems.  This included
> some experiments with RelocationHolder for JDK-8160404.
> 
> This is a modification of the Style Guide, so rough consensus among the
> HotSpot Group members is required to make this change. Only Group members
> should vote for approval (via the github PR), though reasoned objections or
> comments from anyone will be considered. A decision on this proposal will not
> be made before Friday 18-Mar-2022 at 12h00 UTC.
> 
> Since we're piggybacking on github PRs here, please use the PR review process
> to approve (click on Review Changes > Approve), rather than sending a "vote:
> yes" email reply that would be normal for a CFV.

Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7704