Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8282392: [zero] Build broken on AArch64 #7633

Closed
wants to merge 2 commits into from

Conversation

a74nh
Copy link
Contributor

@a74nh a74nh commented Feb 28, 2022


Progress

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

Issue

Reviewers

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
Copy link

bridgekeeper bot commented Feb 28, 2022

👋 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
Copy link

openjdk bot commented Feb 28, 2022

@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.

@openjdk openjdk bot added hotspot hotspot-dev@openjdk.org rfr Pull request is ready for review labels Feb 28, 2022
@mlbridge
Copy link

mlbridge bot commented Feb 28, 2022

Webrevs

@openjdk
Copy link

openjdk bot commented Feb 28, 2022

@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).

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Feb 28, 2022
@a74nh
Copy link
Contributor Author

a74nh commented Feb 28, 2022

/integrate

@openjdk openjdk bot added the sponsor Pull request is ready to be sponsored label Feb 28, 2022
@openjdk
Copy link

openjdk bot commented Feb 28, 2022

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

Copy link
Member

@shipilev shipilev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

See for example:

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

@theRealAph
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Contributor Author

a74nh commented Feb 28, 2022

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)

Copy link
Member

@shipilev shipilev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine, let's do it in this form.

@nsjian
Copy link

nsjian commented Mar 1, 2022

/sponsor

@openjdk
Copy link

openjdk bot commented Mar 1, 2022

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 openjdk bot added the integrated Pull request has been integrated label Mar 1, 2022
@openjdk openjdk bot closed this Mar 1, 2022
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Mar 1, 2022
@openjdk
Copy link

openjdk bot commented Mar 1, 2022

@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
Copy link
Member

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.

@a74nh a74nh deleted the zero_aarch64 branch Mar 1, 2022
@theRealAph
Copy link
Contributor

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
Copy link
Member

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

@magicus
Copy link
Member

magicus commented Mar 1, 2022

@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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot hotspot-dev@openjdk.org integrated Pull request has been integrated
6 participants