-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8325587: Shenandoah: ShenandoahLock should allow blocking in VM #17813
8325587: Shenandoah: ShenandoahLock should allow blocking in VM #17813
Conversation
ab70d4e
to
8f9da4f
Compare
👋 Welcome back shade! A progress list of the required criteria for merging this PR into |
Think about if you can add missing pieces to: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/spinYield.hpp |
fbd242a
to
42bcbe8
Compare
Thought about it. The way current patch is done, there is little leeway to make the code common or reuse it, unfortunately. |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know to little about Shenandoah to say if blocking is always okay, sorry.
Other than that I don't spot any issues, had some minor suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work!
I'll review it, but as stated don't trust me that it's works :)
Looks good, thanks!
@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:
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 114 new commits pushed to the
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I have one question (and leave it up to you to make the change).
Thanks,
Roman
Thanks! /integrate |
Going to push as commit 492e8bf.
Your commit was automatically rebased without conflicts. |
/backport jdk21u-dev |
@mmyxym the backport was successfully created on the branch backport-mmyxym-492e8bf5 in my personal fork of openjdk/jdk21u-dev. To create a pull request with this backport targeting openjdk/jdk21u-dev:master, just click the following link: The title of the pull request is automatically filled in correctly and below you find a suggestion for the pull request body:
If you need to update the source branch of the pull then run the following commands in a local clone of your personal fork of openjdk/jdk21u-dev:
|
/backport jdk22u-dev |
@mmyxym The target repository |
/backport jdk22u |
@mmyxym the backport was successfully created on the branch backport-mmyxym-492e8bf5 in my personal fork of openjdk/jdk22u. To create a pull request with this backport targeting openjdk/jdk22u:master, just click the following link: The title of the pull request is automatically filled in correctly and below you find a suggestion for the pull request body:
If you need to update the source branch of the pull then run the following commands in a local clone of your personal fork of openjdk/jdk22u:
|
ShenandoahLock
is a spinlock that is supposed to guard heap state. That lock is normally only lightly contended, as threads normally only allocate large TLABs/GCLABs. So we just summarily delegated toThread::{SpinAcquire,SpinRelease}
, which spins a bit, and then starts going to sleep/yield dance on contention.This does not work well when there are lots of threads near the OOM conditions. Then, most of these threads would fail to allocate the TLAB, go for out-of-TLAB alloc, start lock acquisition, and spend a lot of time trying to acquire the lock. The handshake/safepoint would think those threads are running, even when they are actually yielding or sleeping. As seen in bug report, a handshake operation over many such threads could then take hundreds of seconds.
The solution is to notify VM that we are blocking before going for
sleep
oryield
. This is similar to what other VM code does near such yields. This involves state transitions, so it is only cheap to do near the actual blocking. Protecting the whole lock with VM transition would be very slow.I also de-uglified bits of adjacent code.
Additional testing:
hotspot_gc_shenandoah
all
passes with-XX:+UseShenandoahGC
(some old failures, but quite a few "timeouts" also disappear)Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/17813/head:pull/17813
$ git checkout pull/17813
Update a local copy of the PR:
$ git checkout pull/17813
$ git pull https://git.openjdk.org/jdk.git pull/17813/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 17813
View PR using the GUI difftool:
$ git pr show -t 17813
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/17813.diff
Webrev
Link to Webrev Comment