8297912: HotSpot Style Guide should permit alignas (Second Proposal Attempt)

[TheShermanTanker]

8252584 was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time

(The changes in this commit are exactly identical to 8252584)

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8297912: HotSpot Style Guide should permit alignas (Second Proposal Attempt)

Reviewers

• Kim Barrett (@kimbarrett - Reviewer) ⚠️ Review applies to 2fb10863
• Thomas Stuefe (@tstuefe - Reviewer) ⚠️ Review applies to 792b96a2
• Vladimir Kozlov (@vnkozlov - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/11446/head:pull/11446
$ git checkout pull/11446

Update a local copy of the PR:
$ git checkout pull/11446
$ git pull https://git.openjdk.org/jdk pull/11446/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 11446

View PR using the GUI difftool:
$ git pr show -t 11446

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/11446.diff

[bridgekeeper]

👋 Welcome back jwaters! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@TheShermanTanker The following labels will be automatically applied to this pull request:

• build
• hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[TheShermanTanker]

/label remove build

[openjdk]

@TheShermanTanker
The build label was successfully removed.

[mlbridge]

Webrevs

• 02: Full - Incremental (33759314)
• 01: Full - Incremental (792b96a2)
• 00: Full (2fb10863)

[tstuefe]

Hi Julian,

could you give this PR/JBS please a speaking name, e.g. "HotSpot Style Guide should permit alignas
(second attempt)". Nobody remembers all JBS issue numbers :)

Also, @rose00 voiced concerns in the original PR (#11315 (comment)) which should be addressed first. I cautiously share his concerns for the moment.

Cheers, Thomas

[kimbarrett]

could you give this PR/JBS please a speaking name, e.g. "HotSpot Style Guide should permit alignas (second attempt)". Nobody remembers all JBS issue numbers :)

+1

Also, @rose00 voiced concerns in the original PR (#11315 (comment)) which should be addressed first. I cautiously share his concerns for the moment.

I had somewhat similar concerns to @rose00 at one point. We have
ATTRIBUTE_ALIGNED for this sort of thing; is alignas actually better? I
think it is, though perhaps weakly. It's a bit shorter and less noisy (which
some might not consider a positive). It is in most respects equivalent to our
macro, and will work for other compilers (I think there are some) without
needing to specialize the macro.

The proposal seems like a lot of words, describing significant restrictions.
The thing is, very nearly all of those words apply to our ATTRIBUTE_ALIGNED
macro too, but aren't written down anywhere.

So I approve of this change, though I won't be heartbroken if it is rejected.
If it's rejected, I'll mine it for documentation comments for our macro.

[kimbarrett]

Looks good.

[openjdk]

@TheShermanTanker This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8297912: HotSpot Style Guide should permit alignas (Second Proposal Attempt)

Reviewed-by: kbarrett, stuefe, kvn

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 201 new commits pushed to the master branch:

• 0ef3539: 8298416: Console should be declared sealed
• 831b35f: 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected
• 0288210: 8298859: ProblemList java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all
• b17c524: 8298059: Linked stack watermarks don't support nesting
• 98fa48c: 8298093: improve cleanup and error handling of awt_parseColorModel in awt_parseImage.c
• 5f63f7a: 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds
• 3ae7187: 8298498: sun/net/www/http/KeepAliveCache/B8291637.java fails with "Server exception terminating: java.net.SocketException: Socket closed"
• b9074fa: 8298249: Excessive memory allocation in CipherInputStream AEAD decryption
• 10bc86c: Merge
• 80cadd4: 8298785: gc/TestFullGCCount.java fails with "invalid boolean value: null' for expression vm.opt.ExplicitGCInvokesConcurrent'"
• ... and 191 more: https://git.openjdk.org/jdk/compare/a71d91b96f7936dd1b84e4c1e167e2e5fa4ad4b1...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[TheShermanTanker]

Also, @rose00 voiced concerns in the original PR (#11315 (comment)) which should be addressed first. I cautiously share his concerns for the moment.

I actually missed John's concerns, but it seems like @kimbarrett has already beaten me to it in remarking that there's almost no difference (if at all) between alignas and the different syntax ATTRIBUTE_ALIGNED expands to, except for the former being a little stricter in certain cases (but this is not always a bad thing). For what it's worth though, Visual C++ does explicitly mention that both the __declspec and alignas are identical, and strongly encourages using the C++ keyword instead

I feel like this is one of those instances where there isn't much that would make one lean more towards either rejecting or accepting the change, but alignas is somewhat better defined than the compiler extensions, which is (at least to me) a small win

[vnkozlov]

I would vote for using C++ feature which provides similar functionality just to avoid supporting our own implementation.
To have our own implementation was justified before as John R. commented.
That is assuming ALL C++ compilers we use today to compile HotSpot code do exactly the same thing.
So before approving this change we need to make sure we (Oracle and OpenJDK community) test #11431 on all our platforms.

[kimbarrett]

A benefit of alignas is that the argument can be a type, in which case it's
alignment is used. gcc's __attribute__((aligned(N))) requires N be the
alignment value.

One could obtain that from a type using alignof(T) or
std::alignment_of<T> (though alignof is not yet approved for use in
HotSpot - JDK-8274400).

Also, the alternative of using std::aligned_storage or std::aligned_union has
problems - JDK-8298399.

Another advantage compared to our macro workaround is that this isn't
something that can be optional for a port. Some uses may really require the
alignment request be honored, such as aligning a char[] for use as aligned
storage. If a port doesn't define ATTRIBUTE_ALIGNED (so uses the empty
default) then we can't use it for that purpose in shared code. (Note that
globalDefinitions_xlc.hpp does NOT define this macro. That's potentially a
bug.)

[kimbarrett]

The MSVC implementation of ATTRIBUTE_ALIGNED using __declspec(align(N)) has the same
limitation of needing the alignment value, and not being usable for types.

I happened to run into both the limitation to alignment values problem and
the lack of an XLC definition for ATTRIBUTE_ALIGNED today.

[tstuefe]

Okay, I'm convinced.

[TheShermanTanker]

Don't mind me, just making it look a little better

[TheShermanTanker]

I'll leave integration of this up to someone else from the HotSpot Group, for convenience

[TheShermanTanker]

/integrate delegate

[openjdk]

@TheShermanTanker Integration of this pull request has been delegated and may be completed by any project committer using the /integrate pull request command.

[vnkozlov]

Per process I approve these changes.

[vnkozlov]

/integrate

[openjdk]

Going to push as commit ae8988e.
Since your change was applied there have been 201 commits pushed to the master branch:

• 0ef3539: 8298416: Console should be declared sealed
• 831b35f: 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected
• 0288210: 8298859: ProblemList java/awt/Mouse/EnterExitEvents/DragWindowTest.java on macosx-all
• b17c524: 8298059: Linked stack watermarks don't support nesting
• 98fa48c: 8298093: improve cleanup and error handling of awt_parseColorModel in awt_parseImage.c
• 5f63f7a: 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds
• 3ae7187: 8298498: sun/net/www/http/KeepAliveCache/B8291637.java fails with "Server exception terminating: java.net.SocketException: Socket closed"
• b9074fa: 8298249: Excessive memory allocation in CipherInputStream AEAD decryption
• 10bc86c: Merge
• 80cadd4: 8298785: gc/TestFullGCCount.java fails with "invalid boolean value: null' for expression vm.opt.ExplicitGCInvokesConcurrent'"
• ... and 191 more: https://git.openjdk.org/jdk/compare/a71d91b96f7936dd1b84e4c1e167e2e5fa4ad4b1...master

Your commit was automatically rebased without conflicts.

[openjdk]

@vnkozlov Pushed as commit ae8988e.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

[TheShermanTanker]

@kimbarrett Now that alignas has officially been approved, is there anything I need to do with 8250269: Replace ATTRIBUTE_ALIGNED with alignas? I'm not sure if there's anything else needed on my part for that issue