8350483: AArch64: turn on signum intrinsics by default on Ampere CPUs

[cnqpzhang]

Backport the commit to set -XX:+UseSignumIntrinsic by default for Ampere CPUs. It is to fix performance problem observed on JMH cases vm.compiler.Signum|java.lang.*MathBench.sig[nN]um*. For example, vm.compiler.Signum._1_signumFloatTest thrpt score becomes 30x better on both jdk mainline and jdk17u-dev. The backporting can be very safe as it is limited to Ampere CPUs only and well verified on Ampere-1A with related jmh and jtreg tier1 tests.

---

Progress

• Change must not contain extraneous whitespace
• JDK-8350483 needs maintainer approval
• Commit message must refer to an issue

Issue

• JDK-8350483: AArch64: turn on signum intrinsics by default on Ampere CPUs (Enhancement - P4 - Approved)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk17u-dev.git pull/3300/head:pull/3300
$ git checkout pull/3300

Update a local copy of the PR:
$ git checkout pull/3300
$ git pull https://git.openjdk.org/jdk17u-dev.git pull/3300/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3300

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk17u-dev/pull/3300.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

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

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

8350483: AArch64: turn on signum intrinsics by default on Ampere CPUs

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

• 95fe05a: 8136895: Writer not closed with disk full error, file resource leaked
• f7492dd: 8312475: org.jline.util.PumpReader signed byte problem
• 4241313: 8354941: Build failure with glibc 2.42 due to uabs() name collision
• ... and 310 more: https://git.openjdk.org/jdk17u-dev/compare/fd353e38a820eed00b1a5f28e892a4d6baa3f1d1...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.

➡️ 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]

This backport pull request has now been updated with issue from the original commit.

[openjdk]

⚠️ @cnqpzhang This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

[mlbridge]

Webrevs

• 00: Full (6f75fc9c)

[cnqpzhang]

/approval request Resolved a merging conflict as the auto backport covered a piece of unrelated code change on CodeEntryAlignment. Right now, the updated commit has the exact same changes as f529bf71 from the openjdk/jdk repository. The change is simple and straight-forward, the change itself is safely limited to AArch64-port Ampere CPUs only, and well verified on Ampere-1A system, can be safe for backport. Please approve, thanks.

[openjdk]

@cnqpzhang
8350483: The approval request has been created successfully.

[GoeLin]

Hi @cnqpzhang ,
can you please backport to 24 and 21 first? Removing the label in the meantime. Performance optimizations are not necessarily good candidates for backport to a rather old release.

[cnqpzhang]

Hi @cnqpzhang , can you please backport to 24 and 21 first? Removing the label in the meantime. Performance optimizations are not necessarily good candidates for backport to a rather old release.

Thanks for your comments, @GoeLin .
Sure I will request for backports to 24 and 21 firstly.
It is not just a performance optimization, in the worst cases the slowdown caused by the performance issue showed 80~100x time cost of normal cases, as such the functions at 1~2% of the expected run speed got severely impacted in a manner.

[bridgekeeper]

@cnqpzhang This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[cnqpzhang]

/approval cancel

[openjdk]

@cnqpzhang
8350483: The approval request has been cancelled successfully.

[cnqpzhang]

Status update: backport to 24 has been done (merged), and the operation to 21 is waiting for a dependent change, and 17 would follow up.

[cnqpzhang]

/approval request Should get backported to 17u for parity with 21u and 24u which have been done. Low risk and tier1 tests and other sanity checks pass on Ampere-1A systems. Initially intended as a performance optimization but later on found saving up to 80~100x performance defect in certain extreme cases. The issue severely impacted signum functions. Given that 17u is still extensively used by Java devs in practice, addressing this problem is essential to retore performance and maintain platform reliability. Thanks for approval.

[openjdk]

@cnqpzhang
8350483: The approval request has been created successfully.

[GoeLin]

Hi @cnqpzhang
Thanks for backporting to 21 and 24.
One question: is this a regression? Can you name the change that cause the performance regression? Or is this a true optimization.

[cnqpzhang]

Hi @cnqpzhang Thanks for backporting to 21 and 24. One question: is this a regression? Can you name the change that cause the performance regression? Or is this a true optimization.

Not a regression, the option was only enabled for some specific CPUs while this commit/backport extends its benefit to more.

[bridgekeeper]

@cnqpzhang This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[cnqpzhang]

/keepalive for approval and merge

[openjdk]

@cnqpzhang The pull request is being re-evaluated and the inactivity timeout has been reset.

[bridgekeeper]

@cnqpzhang This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[cnqpzhang]

/integrate

[openjdk]

@cnqpzhang
Your change (at version 6f75fc9) is now ready to be sponsored by a Committer.

[cnqpzhang]

Hi @GoeLin , could you please help sponsor this and push? With sincere thanks.