-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8307236: Rendezvous GC threads under STS for monitor deflation #13773
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
Conversation
👋 Welcome back rkennke! A progress list of the required criteria for merging this PR into |
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.
Looks good.
@rkennke 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 33 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 |
// Also, we sync and desync GC threads around the handshake, so that they can | ||
// safely read the mark-word and look-through to the object-monitor, without | ||
// being afraid that the object-monitor is going away. | ||
VM_RendezvousGCThreads sync_gc; | ||
VMThread::execute(&sync_gc); |
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.
Not sure why this block is under current->is_Java_thread()
block. Shouldn't we rendezvous with GC threads regardless?
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.
Not sure why this block is under
current->is_Java_thread()
block. Shouldn't we rendezvous with GC threads regardless?
Deflation is done either concurrently by the service thread, or in a safepoint by the VM thread. The current->is_Java_thread() means it's the concurrent case from the service thread. That's when it's needed. Inside of safepoints, the GC threads have already been synchronized.
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.
Okay, I see. Can we then move this block into separate current->is_service_thread()
-checked block, and assert(current->is_VM_thread())
on else
branch? This would make this distinction very clear.
|
||
if (ls != nullptr) { | ||
ls->print_cr("after handshaking: in_use_list stats: ceiling=" | ||
SIZE_FORMAT ", count=" SIZE_FORMAT ", max=" SIZE_FORMAT, | ||
in_use_list_ceiling(), _in_use_list.count(), _in_use_list.max()); | ||
timer.start(); | ||
} | ||
} else { | ||
assert(current->is_VM_thread(), "only VM thread may get here"); |
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.
Actually, maybe we should assert we are at safepoint? To protect the accidental call from the VMOp that is executed by VMThread, but outside of safepoint.
} else {
// This is not a monitor deflation thread.
// No handshake or rendezvous is needed when we are already at safepoint.
assert_at_safepoint();
}
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.
This looks fine to me. @fisk and/or @dcubed-ojdk might want to re-review :)
Thanks! |
Going to push as commit 12d6ec6.
Your commit was automatically rebased without conflicts. |
Object monitors are deflated concurrently by the MonitorDeflationThread. It first unlinks monitors from objects (i.e. restore the original object header), then handshakes (with a no-op) all Java threads, and only then destroys the monitors. This way, Java threads can safely (and racily) access monitors before the handshake, because the monitors are guaranteed to still exist when a Java thread racily reads a mark-word that is being unlinked, and the monitor can safely be destroyed after the handshake, because all Java threads would then read the correct unlinked mark-word.
However, GC threads are not rendezvous'ed like that, and can read potentially dead monitors. At least with the upcoming Compact Object Headers this is going to be a problem, because the compressed Klass* is then part of the mark-word.
In order to safely access monitors via object headers concurrently from GC threads, we need to rendezvous them after unlinking and before destroying the monitors, just like Java threads do, via handshake. This is important so that concurrent GCs (ZGC, Shenandoah, G1) can safely access object's Klass* (and thus object size, layout, etc) during concurrent GC phases.
This only implements the parts that do the rendezvous, it still requires that affected concurrent GC threads are under SustainableThreadSet (most of them already are!). This will be implemented in later PR.
Testing:
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13773/head:pull/13773
$ git checkout pull/13773
Update a local copy of the PR:
$ git checkout pull/13773
$ git pull https://git.openjdk.org/jdk.git pull/13773/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 13773
View PR using the GUI difftool:
$ git pr show -t 13773
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13773.diff
Webrev
Link to Webrev Comment