8324186: Use "dmb.ishst+dmb.ishld" for release barrier

[kuaiwei]

Details is https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2024-January/071921.html.
Using a combined dmb.ish for release barrier will introduce a heavy storeload barrier. Use "dmb.ishst+dmb.ishld" pair instead, we can gain performance improvement on N1 and N2 architecture. The benchmark is test/micro/org/openjdk/bench/vm/compiler/FinalFieldInitialize.java
Run with ParallelGC to minimalize impact of gc barrier.

make test TEST="micro:org.openjdk.bench.vm.compiler.FinalFieldInitialize" MICRO="VM_OPTIONS=-XX:+UseParallelGC"
...
FinalFieldInitialize.testAllocWithFinal  thrpt    9  1411.601 ?  6.546  ops/s

Without the patch

FinalFieldInitialize.testAllocWithFinal  thrpt    9  1214.575 ? 14.217  ops/s

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8324186: use "dmb.ishst+dmb.ishld" for release barrier (Enhancement - P4)

Reviewers

• Fei Yang (@RealFYang - Reviewer)
• Andrew Haley (@theRealAph - Reviewer) ⚠️ Review applies to f817bb25

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/17511/head:pull/17511
$ git checkout pull/17511

Update a local copy of the PR:
$ git checkout pull/17511
$ git pull https://git.openjdk.org/jdk.git pull/17511/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 17511

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/17511.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

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

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

• 03: Full - Incremental (b842951d)
• 02: Full - Incremental (056c1859)
• 01: Full - Incremental (e4081bc9)
• 00: Full (f817bb25)

[RealFYang]

I wonder if this was tested on other vendors' hardware? I witnessed some negative impact at least on HiSilicon TSV110 running the same JMH. So I guess it might be safer to go as a vendor-specific change.

Before:
Benchmark                                 Mode  Cnt    Score    Error  Units
FinalFieldInitialize.testAllocWithFinal  thrpt    9  840.267 ? 69.505  ops/s

After:
Benchmark                                 Mode  Cnt    Score     Error  Units
FinalFieldInitialize.testAllocWithFinal  thrpt    9  732.791 ?  47.198  ops/s

[nick-arm]

Could we instead make the last store to a final field in a constructor an STLR and remove the release barrier?

[theRealAph]

Very nice. Thanks.

[theRealAph]

Could we instead make the last store to a final field in a constructor an STLR and remove the release barrier?

It's possible, but it would be more work.

[theRealAph]

I wonder if this was tested on other vendors' hardware? I witnessed some negative impact at least on HiSilicon TSV110 running the same JMH. So I guess it might be safer to go as a vendor-specific change.

That's interesting, but I guess it's only 14% on a microbenchmark which is intended to stress this as much as possible. Do we have any idea why this regresses?

[nick-arm]

I wonder if this was tested on other vendors' hardware? I witnessed some negative impact at least on HiSilicon TSV110 running the same JMH. So I guess it might be safer to go as a vendor-specific change.

I tried a number of different machines and saw regressions only on Kunpeng-920 (same CPU?) and A57 which is quite niche at this point.

[kuaiwei]

Could we instead make the last store to a final field in a constructor an STLR and remove the release barrier?

It's possible, but it would be more work.

I tried it before and failed. We can not bind the final field store with stlr, because the store which publish the new obj to heap can float above and cause trouble. It may work if bind the stlr with the publish store. But we may add multiple stlr.

[kuaiwei]

I wonder if this was tested on other vendors' hardware? I witnessed some negative impact at least on HiSilicon TSV110 running the same JMH. So I guess it might be safer to go as a vendor-specific change.

I tried a number of different machines and saw regressions only on Kunpeng-920 (same CPU?) and A57 which is quite niche at this point.

Thanks for test on other architecture. We may need a new arch dependent flag for it.

[RealFYang]

I wonder if this was tested on other vendors' hardware? I witnessed some negative impact at least on HiSilicon TSV110 running the same JMH. So I guess it might be safer to go as a vendor-specific change.

I tried a number of different machines and saw regressions only on Kunpeng-920 (same CPU?) and A57 which is quite niche at this point.

@nick-arm : Thanks for trying it out. Yeah, TSV110 is the core micro-arch name for Kunpeng-920. @theRealAph : I don't have access to the details of TSV110 any more, I guess it's not easy to figure out what's going on :-(

[theRealAph]

I wonder if this was tested on other vendors' hardware? I witnessed some negative impact at least on HiSilicon TSV110 running the same JMH. So I guess it might be safer to go as a vendor-specific change.

I tried a number of different machines and saw regressions only on Kunpeng-920 (same CPU?) and A57 which is quite niche at this point.

Right, so it's probably a low-end, mostly-in-order thing. That makes sense because we're trading a weaker barrier for more instructions, and perhaps some cores implement barriers in a crude one-size-fits-all way.

[RealFYang]

LGTM. Thanks.

[openjdk]

@kuaiwei This pull request has not yet been marked as ready for integration.

[openjdk]

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

8324186: Use "dmb.ishst+dmb.ishld" for release barrier

Reviewed-by: fyang, aph

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

• 62b3293: 8324241: Always record evol_method deps to avoid excessive method flushing
• 885e9b7: 8324722: Serial: Inline block_is_obj of subclasses of Generation
• 32ddcf5: 8324301: Obsolete MaxGCMinorPauseMillis
• c313d45: 8324659: GHA: Generic jtreg errors are not reported
• 781f368: 8324347: Enable "maybe-uninitialized" warning for FreeType 2.13.1
• 33324a5: 8324637: [aix] Implement support for reporting swap space in jdk.management
• 10066cd: 8324571: JDK 23 L10n resource files update
• bde8789: 8324123: aarch64: fix prfm literal encoding in assembler
• b5995a7: 8302019: Clarify Elements.overrides
• 95310ea: 8223696: java/net/httpclient/MaxStreams.java failed with didn't finish within the time-out
• ... and 50 more: https://git.openjdk.org/jdk/compare/2003610b3b52eed04de6713a2a36151d0d86d7c9...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 (@RealFYang, @theRealAph) 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).

[kuaiwei]

/integrate

[openjdk]

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

[kuaiwei]

@theRealAph @RealFYang Could you help to sponsor it? Thanks

[theRealAph]

/sponsor

[openjdk]

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

• 72ba817: 8324236: compiler/ciReplay/TestInliningProtectionDomain.java failed with RuntimeException: should only dump inline information for ... expected true, was false
• b39b876: 8324304: RISC-V: add hw probe flags
• 69586e7: 8322996: BoxLockNode creation fails with assert(reg < CHUNK_SIZE) failed: sanity
• f0bae79: 8324750: C2: rename Matcher methods using "superword" -> "autovectorization"
• 6ad78ca: 8324775: C2 SuperWord: refactor visited sets
• 422020c: 8210858: AArch64: remove Math.log intrinsic
• 0d5f5e1: 8322484: 22-b26 Regression in J2dBench-bimg_misc-G1 (and more) on Windows-x64 and macOS-x64
• af9cd97: 8324800: gcc windows build broken after 8322757
• 8950d68: 8324753: [AIX] adjust os_posix after JDK-8318696
• 65d6bc1: 8324765: C2 SuperWord: remove dead code: SuperWord::insert_extracts
• ... and 67 more: https://git.openjdk.org/jdk/compare/2003610b3b52eed04de6713a2a36151d0d86d7c9...master

Your commit was automatically rebased without conflicts.

[openjdk]

@theRealAph @kuaiwei Pushed as commit 628348d.

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

[TobiHartmann]

This introduced a performance regression, see JDK-8325449 and JDK-8325269. @kuaiwei, could you please have a look?

[kuaiwei]

This introduced a performance regression, see JDK-8325449 and JDK-8325269. @kuaiwei, could you please have a look?

I missed the message. I will look these issues.