-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
8273917: Remove 'leaf' ranking for Mutex #5801
Conversation
@@ -1206,7 +1206,8 @@ void MethodData::post_initialize(BytecodeStream* stream) { | |||
// Initialize the MethodData* corresponding to a given method. | |||
MethodData::MethodData(const methodHandle& method) | |||
: _method(method()), | |||
_extra_data_lock(Mutex::leaf, "MDO extra data lock", Mutex::_safepoint_check_always), | |||
// Holds Compile_lock | |||
_extra_data_lock(Mutex::nonleaf-2, "MDOExtraData_lock", Mutex::_safepoint_check_always), |
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.
MDO lock (nonleaf-2) is taken when the Compile_lock is held (nonleaf-1) which is taken while the MethodCompileQueue_lock (nonleaf) is held.
👋 Welcome back coleenp! A progress list of the required criteria for merging this PR into |
Webrevs
|
According to my logging, the shenandoah locks don't have any dependencies when running runThese with shenandoah, but could someone confirm this is ok to make them nonleaf? @zhengyu123 ? _wait_monitor (should rename to a consistent lock name) depends on PeriodicTask_lock: |
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 think this is a step in the right direction, and I heard great things will come in the next patch. Thanks for reducing the changes to nonleaf - 2. Go Coleen, go! Also looks good.
@coleenp 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 40 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 |
Thank you Erik! |
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.
Hi Coleen,
A minor comment below but otherwise this all seems okay.
Thanks,
David
Thank you for reviewing, David. |
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.
Thanks for that tweak.
David
Thanks for the reviews Erik and David. |
Going to push as commit b8af6a9.
Your commit was automatically rebased without conflicts. |
This change removes 'leaf' ranking. The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always.
The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the top mutex rank.
The transformation in this change is as follows:
nonleaf+n => nonleaf - Generally these 'nonleaf' mutex were top level locks)
leaf => nonleaf - Many of these locks were top level locks
leaf => nonleaf-2 - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock
leaf-n => nonleaf-n
The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2.
This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it. So these relative mutex are moved to the end of the init function in mutexLocker.cpp.
This has been tested with tier1-8, and retesting tier1-3 locally in progress.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5801/head:pull/5801
$ git checkout pull/5801
Update a local copy of the PR:
$ git checkout pull/5801
$ git pull https://git.openjdk.java.net/jdk pull/5801/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 5801
View PR using the GUI difftool:
$ git pr show -t 5801
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5801.diff