8257396: AArch64 Zero build is broken after JDK-8252684

[shipilev]

Zero does not have AArch64 assembler, so attempt to use it from the test fails to build. The fix is trivial: sense if we are building Zero.

Testing:

• Linux aarch64 zero build

---

Progress

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

Testing

	Linux additional	Linux x64	Linux x86	Windows x64	macOS x64
Build	✔️ (8/8 passed)	✔️ (2/2 passed)	✔️ (2/2 passed)	✔️ (2/2 passed)	✔️ (2/2 passed)
Test (tier1)		✔️ (9/9 passed)	✔️ (9/9 passed)	✔️ (9/9 passed)	✔️ (9/9 passed)

Issue

• JDK-8257396: AArch64 Zero build is broken after JDK-8252684

Reviewers

• David Holmes (@dholmes-ora - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/1511/head:pull/1511
$ git checkout pull/1511

[bridgekeeper]

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

@shipilev To determine the appropriate audience for reviewing this pull request, one or more labels corresponding to different subsystems will normally be applied automatically. However, no automatic labelling rule matches the changes in this pull request. In order to have an "RFR" email sent to the correct mailing list, you will need to add one or more applicable labels manually using the /label pull request command.

Applicable Labels

• 2d
• awt
• beans
• build
• compiler
• core-libs
• hotspot
• hotspot-compiler
• hotspot-gc
• hotspot-jfr
• hotspot-runtime
• i18n
• javadoc
• jdk
• jmx
• kulla
• net
• nio
• security
• serviceability
• shenandoah
• sound
• swing

[shipilev]

/label hotspot

[openjdk]

@shipilev
The hotspot label was successfully added.

[mlbridge]

Webrevs

• 00: Full (403c60b)

[dholmes-ora]

Lets hope this is the last adjustment needed in relation to this change.

Thanks,
David

[openjdk]

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

8257396: AArch64 Zero build is broken after JDK-8252684

Reviewed-by: dholmes

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

• 962f7a3: 8257162: Initialize ThreadLocalAllocBuffer members
• 337d7bc: 8257165: C2: Improve box elimination for vector masks and shuffles
• 4e55d0f: 8257057: C2: Improve safepoint processing during vector scalarization pass

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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.

[mlbridge]

Mailing list message from Andrew Haley on hotspot-dev:

On 11/30/20 12:37 PM, David Holmes wrote:

On Mon, 30 Nov 2020 08:49:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

Zero does not have AArch64 assembler, so attempt to use it from the test fails to build. The fix is trivial: sense if we are building Zero.

Testing:
- [x] Linux aarch64 zero build

Lets hope this is the last adjustment needed in relation to this change.

Aren't the pre-integration tests supposed to pick up this kind of thing?

--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

[shipilev]

Lets hope this is the last adjustment needed in relation to this change.

All builds are green for me, except AArch64 Zero.

Aren't the pre-integration tests supposed to pick up this kind of thing?

GH actions do not build AArch64 Zero. GH actions build both x86_64 Zero and AArch64 Server. My CIs, on the other hand, make a point to build every configuration out there every night -- at expense of CPU time spent on it -- and thus capture even the odd corner cases like these.

[shipilev]

/integrate

[openjdk]

@shipilev Since your change was applied there have been 24 commits pushed to the master branch:

• 353e791: 8257398: Enhance debug output in Type::check_symmetrical
• f48737c: 8256254: Convert vmIntrinsics::ID to enum class
• b5ce8af: 8256373: [Windows/HiDPI] The Frame#setBounds does not work in a minimized state
• 0eaf0bb: 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr
• 822ee47: 8257242: [macOS] Java app crashes while switching input methods
• 7d89852: 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files
• 4356469: 8230501: Class data support for hidden classes
• 11dad14: 8257445: (zipfs) Add DataProvider to TestLocOffsetFromZip64EF.java
• 29f86e0: 8256536: Newer AMD 19h (EPYC) Processor family defaults
• 7f58a8e: 8213719: Both sect163r2 and sect163k1 are default curves for field size 163
• ... and 14 more: https://git.openjdk.java.net/jdk/compare/e77aed624ec2e230cde71cd21622397cf115f1f6...master

Your commit was automatically rebased without conflicts.

Pushed as commit 13bd2e8.

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

[mlbridge]

Mailing list message from David Holmes on hotspot-dev:

On 30/11/2020 11:29 pm, Andrew Haley wrote:

On 11/30/20 12:37 PM, David Holmes wrote:

On Mon, 30 Nov 2020 08:49:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

Zero does not have AArch64 assembler, so attempt to use it from the test fails to build. The fix is trivial: sense if we are building Zero.

Testing:
- [x] Linux aarch64 zero build

Lets hope this is the last adjustment needed in relation to this change.

Aren't the pre-integration tests supposed to pick up this kind of thing?

Not for the zero case as Aleksey indicated.

And JDK-8252684 was integrated despite the failures in the
pre-integration testing.

David
-----