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 - Requested)

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]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

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