8293922: Extend barrier-less Java thread transitions to native transitions

[robehn]

As suggested by @TheRealMDoerr, avoid the fence for native trans when UseSystemMemoryBarrier is enabled.

Locally I can see methods like Thread.holdsLock() getting a 4 ns speed boost, (~20% faster).

Running t1-5 with UseSystemMemoryBarrier on.

---

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-8293922: Extend barrier-less Java thread transitions to native transitions

Reviewers

• Martin Doerr (@TheRealMDoerr - Reviewer)
• Patricio Chilano Mateo (@pchilano - Reviewer)
• Daniel D. Daugherty (@dcubed-ojdk - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 10302

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

Using diff file

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

[bridgekeeper]

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

@robehn The following label will be automatically applied to this pull request:

• hotspot-runtime

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

• 01: Full - Incremental (52bad66c)
• 00: Full (d1f143ed)

[TheRealMDoerr]

Very cool! Both, _thread_state and _polling_word are volatile, so the C++ compiler is not allowed to mess up the accesses. The speedup should more than justify the overhead of the SYS_membarrier call. I hope that we can use it in production at some point of time.

[openjdk]

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

8293922: Extend barrier-less Java thread transitions to native transitions

Reviewed-by: mdoerr, pchilanomate, dcubed

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

• f91762f: 8293965: Code signing warnings after JDK-8293550
• 8082c24: 8054572: [macosx] JComboBox paints the border incorrectly
• b920d29: 8271328: User is able to choose the color after disabling the color chooser.
• 5725a93: 8293879: Remove unnecessary castings in jdk.hotspot.agent
• ab7f58a: 6286501: JTabbedPane throws NPE from its stateChanged listener in particular case
• d41f69f: 8293849: PrintIdealPhase in compiler directives file is ignored when used with other compile commands
• 471e2f1: 8292088: C2: assert(is_OuterStripMinedLoop()) failed: invalid node class: IfTrue
• a93cf92: 8293920: G1: Add index based heap region iteration
• 36c9034: 8293808: mscapi destroyKeyContainer enhance KeyStoreException: Access is denied exception
• cbd0688: 8293851: hs_err should print more stack in hex dump
• ... and 21 more: https://git.openjdk.org/jdk/compare/3beca2db0761f8172614bf1b287b694c8595b498...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.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[robehn]

Thanks, great.

But since you bring it up. We should use correct accessors for _thread_state.
Fixed that, please have a second look @TheRealMDoerr.

[TheRealMDoerr]

Thanks for cleaning it up!

[robehn]

Thanks for cleaning it up!

Thank you!

[pchilano]

Looks good. Can't we do the same in ~ThreadBlockInVMPreprocess() for the blocked transition?

[dcubed-ojdk]

Thumbs up.

I do have to wonder why we had those casts that you removed.

[dcubed-ojdk]

Can't we do the same in ~ThreadBlockInVMPreprocess() for the blocked transition?

Perhaps, but please use a new RFE/bug for that.

[robehn]

The casts came from the time when the atomics didn't use templates, so it only supported integer types.

TBIVM should not really notice any difference, since it mostly used together with VM Mutex, thus must emit a fence on front edge. As Dan says, do a separate RFE if you like it to be consistent.

Thanks for reviewing!

[robehn]

Thanks!

[robehn]

/integrate

[openjdk]

Going to push as commit 1b49606.
Since your change was applied there have been 39 commits pushed to the master branch:

• a07902b: 8293976: Use unsigned integers in Assembler/CodeBuffer::emit_int*
• fe541f0: 8293989: [JVMCI] re-use cleared oop handles
• 0fa7d9e: 8278863: Add method ClassDesc::ofInternalName
• 4020ed5: 8293210: G1: Remove redundant check in G1FreeHumongousRegionClosure
• 8ff2c26: 8293942: [JVMCI] data section entries must be 4-byte aligned on AArch64
• 6e23b43: 8293502: (fc) FileChannel::transfer methods fail to copy /proc files on Linux
• 1f9ff41: 8292297: Fix up loading of override java.security properties file
• 64b96e5: 8293811: Provide a reason for PassFailJFrame.forceFail
• f91762f: 8293965: Code signing warnings after JDK-8293550
• 8082c24: 8054572: [macosx] JComboBox paints the border incorrectly
• ... and 29 more: https://git.openjdk.org/jdk/compare/3beca2db0761f8172614bf1b287b694c8595b498...master

Your commit was automatically rebased without conflicts.

[openjdk]

@robehn Pushed as commit 1b49606.

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