RFR: 8282668: HotSpot Style Guide should permit unrestricted unions

[Kim Barrett]

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.

Response to this proposal has been minimal so far.

I probably should have mentioned that using unrestricted unions involves more
than just wrapping several members of non-trivial type in a `union` form.
There are important effects on some of the special member functions for the
union/class containing the variant members.  See the proposal or the Standard
for details.

The short form is that if a variant-member has a non-trivial ctor/dtor/assign
then the corresponding implicit definition of the enclosing class/union is
deleted; there must be a user-provided definition to use that special function.
Also, if a variant member is not mentioned in a constructor's mem-initializer-list
then it is not initialized, rather than implicitly default initialized.

The idea is that the compiler can't know how to write the correct "default"
version of the function, so it must be provided explicitly.

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

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