8282392: [zero] Build broken on AArch64

[a74nh]

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8282392: [zero] Build broken on AArch64

Reviewers

• Andrew Haley (@theRealAph - Reviewer) ⚠️ Review applies to d5952ab
• Aleksey Shipilev (@shipilev - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/7633/head:pull/7633
$ git checkout pull/7633

Update a local copy of the PR:
$ git checkout pull/7633
$ git pull https://git.openjdk.java.net/jdk pull/7633/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 7633

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/7633.diff

[bridgekeeper]

👋 Welcome back a74nh! 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]

@a74nh The following label will be automatically applied to this pull request:

• hotspot

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

[mlbridge]

Webrevs

• 01: Full - Incremental (edf11eae)
• 00: Full (d5952abc)

[openjdk]

@a74nh 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:

8282392: [zero] Build broken on AArch64

Reviewed-by: aph, shade

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 13 new commits pushed to the master branch:

• 59b3ecc: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName
• 4e7fb41: 8282172: CompileBroker::log_metaspace_failure is called from non-Java/compiler threads
• 0ae3d1d: 8282131: java.time.ZoneId should be a sealed abstract class
• c58f5c6: 8282360: Merge POSIX implementations of ThreadCritical
• 06cadb3: 8230382: Clean up ConvI2L, CastII and CastLL::Ideal methods
• efd3967: 8267265: Use new IR Test Framework to create tests for C2 Ideal transformations
• 86723d4: 8281507: Two javac tests have bad jtreg @clean tags
• 630ad1a: 8282428: ProblemList jdk/jfr/jvm/TestWaste.java
• afd4bcb: 8282398: EndingDotHostname.java test fails because SSL cert expired
• cf6d256: 8282153: JFR: Check for recording waste
• ... and 3 more: https://git.openjdk.java.net/jdk/compare/e96c599ed2a30ea116803aac0e85ba701ad40e25...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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@theRealAph, @shipilev) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[a74nh]

/integrate

[openjdk]

@a74nh
Your change (at version edf11ea) is now ready to be sponsored by a Committer.

[shipilev]

I think it is confusing to have AARCH64_PORT_ONLY defines, to be honest. In the similar cases for X86, we just additionally protect these blocks with !ZERO. Something like:

#if defined(AARCH64) && !defined(ZERO)
ret_pc = pauth_strip_pointer(ret_pc);
#endif

[shipilev]

See for example:

jdk/src/hotspot/share/utilities/ticks.cpp

Line 66 in 4e7fb41

#if defined(X86) && !defined(ZERO)

[theRealAph]

I think it is confusing to have AARCH64_PORT_ONLY defines, to be honest. In the similar cases for X86, we just additionally protect these blocks with !ZERO. Something like:

That's what we looked at and it was more of a mess, IMO. In the end it's a judgment call which to have, and I've seen this kind of mistake, where a particular port is confused with a particular CPU, enough times that I think this is OK; YMMV.

[shipilev]

That's what we looked at and it was more of a mess, IMO. In the end it's a judgment call which to have, and I've seen this kind of mistake, where a particular port is confused with a particular CPU, enough times that I think this is OK; YMMV.

From the perspective of Zero maintenance, having the Zero-specific workarounds explicitly doing !ZERO is cleaner. This mess is mostly Zero-s problem with idenitifying itself as CPU. So, in my mind, there is little reason to accommodate that problem with "port" defines.

[theRealAph]

That's what we looked at and it was more of a mess, IMO. In the end it's a judgment call which to have, and I've seen this kind of mistake, where a particular port is confused with a particular CPU, enough times that I think this is OK; YMMV.

From the perspective of Zero maintenance, having the Zero-specific workarounds explicitly doing !ZERO is cleaner. This mess is mostly Zero-s problem with idenitifying itself as CPU. So, in my mind, there is little reason to accommodate that problem with "port" defines.

I think I understand your point, but IMO it's almost always easier to understand language which says what something is than what it isn't, and a simple name than a boolean expression. And that is more important, I believe.
Having said that, if you insist that flagging this up as a Zero-specific workaround with !ZERO is really important I will give way to your preference. (I don't think it is: I think we should flag this code as port-specific, not CPU-specific. But mostly I just want this patch pushed.)

[a74nh]

My only issue with that is that:
AARCH64_PORT_ONLY(some_function());

becomes:
#if defined(AARCH64) && !defined(ZERO)
some_function();
#endif

Which is a little uglier.

How about defining the macro something like:
#if defined(AARCH64) && !defined(ZERO)
#define AARCH64_NOT_ZERO(code) code

(ultimately, I'm happy with any of the above)

[shipilev]

Fine, let's do it in this form.

[nsjian]

/sponsor

[openjdk]

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

• 7743266: 8281210: Add manpage changes for PAC-RET protection on Linux/AArch64
• 1f89acd: 8282464: Remove author tags from java.compiler
• 9d9618a: 8282462: Remove unnecessary use of @SuppressWarnings("preview")
• d983d10: 8275731: CDS archived enums objects are recreated at runtime
• c7cd148: 8282240: Add _name field to Method for NOT_PRODUCT only
• 59b3ecc: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName
• 4e7fb41: 8282172: CompileBroker::log_metaspace_failure is called from non-Java/compiler threads
• 0ae3d1d: 8282131: java.time.ZoneId should be a sealed abstract class
• c58f5c6: 8282360: Merge POSIX implementations of ThreadCritical
• 06cadb3: 8230382: Clean up ConvI2L, CastII and CastLL::Ideal methods
• ... and 8 more: https://git.openjdk.java.net/jdk/compare/e96c599ed2a30ea116803aac0e85ba701ad40e25...master

Your commit was automatically rebased without conflicts.

[openjdk]

@nsjian @a74nh Pushed as commit c1a28aa.

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

[dholmes-ora]

Sorry I missed this but this is stylistically awful IMHO. What is AARCH64_PORT_ONLY supposed to mean? IIUC it really means AARCH64_NATIVE_PORT_ONLY or AARCH64_NOT_ZERO_ONLY. I would much rather have seen @shipilev request to use a combination of CPU and ZERO to get this right - as used everywhere else when dealing with ZERO.
And we don't use TARGET_ARCH_x anywhere else in the code other than to define the macros.

[theRealAph]

Sorry I missed this but this is stylistically awful IMHO. What is AARCH64_PORT_ONLY supposed to mean? IIUC it really means AARCH64_NATIVE_PORT_ONLY or AARCH64_NOT_ZERO_ONLY. I would much rather have seen @shipilev request to use a combination of CPU and ZERO to get this right - as used everywhere else when dealing with ZERO. And we don't use TARGET_ARCH_x anywhere else in the code other than to define the macros.

I've seen this problem repeating over the years, caused by a failure to distinguish between an ifdef for the properties of a particular CPU and one for the implementation of a particular port. Courtesy of Zero, there is not a 1:1 mapping between these, and (judging by the problems we've seen) it is a frequent cause of confusion. Usually we catch the bugs before push, but not always.

In my opinion that this is not merely a matter of people making mistakes, but of a style that is confusing, and will continue to be.

[dholmes-ora]

I prefer adding the ifndef ZERO to guard these cases than this singular attempt to do something completely different.

[magicus]

@theRealAph Hear, hear!

Zero is causing a conceptual mess the way it is currently "injected" into hotspot. This mess also spills over into the build system.

The core problem is that Zero claims to be a "CPU", which it clearly is not. And then a lot of workarounds needs to be installed everywhere to compensate for this confusion. A better solution would be to go back to CPU meaning just CPU, and introduce a second dimension along which to determine zero/non-zero. We might have to bikeshed for a while to find a good name for this second dimension (I can't come up with any ideal names straight away, anyway. INTERPRETED_ONLY vs COMPILED? ZERO vs NON_ZERO? Or ZERO vs ONE? :-))

Doing this would simplify the concepts and logic behind both the Hotspot code and the build system, and eliminate a class of errors that keep popping up all the time, due to this confusing design decision.

[dholmes-ora]

Zero is a CPU-agnostic interpreter build, but our builds are inherently CPU-based, so Zero has to represent that "don't care" CPU because it has to replace some CPU specific code with Zero's C code. But then you have to build other CPU-specific parts of the JDK even when using Zero. Hence the approach of using CPU ifdefs combined with a check for Zero.
Yes it is awkward and confusing and mistakes can creep in. But I don't think you will come up with anything better for this situation. And the AARCH64_PORT_ONLY is certainly not better IMO.

[theRealAph]

Zero is a CPU-agnostic interpreter build, but our builds are inherently CPU-based, so Zero has to represent that "don't care" CPU because it has to replace some CPU specific code with Zero's C code. But then you have to build other CPU-specific parts of the JDK even when using Zero. Hence the approach of using CPU ifdefs combined with a check for Zero. Yes it is awkward and confusing and mistakes can creep in. But I don't think you will come up with anything better for this situation. And the AARCH64_PORT_ONLY is certainly not better IMO.

Can you explain why it's not better? I don't want to waste your time by prolonging discussions unnecessarily, but it seems to me that this nomenclature conveys exactly what we mean: not so much running on a particular CPU, but a particular port.
There's a matrix of possible combinations of instruction set architecture and port, with the ports ranging from highly-tuned and customized to completely portable, with space in between.

[dholmes-ora]

@theRealAph the word "port" may have a very specific meaning to you such that this macro conveys what you expect, but it doesn't to me. You have to know what is not considered part of a "port" when building Aarch64 - and that is simply when building Zero. So to me Zero should be part of any conditionalisation. e.g. (if macros work this way)

NOT_ZERO(AARCH64_ONLY(ret_pc = pauth_strip_pointer(ret_pc);))

or the ifdefs @shipilev suggested.