-
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
8319773: Avoid inflating monitors when installing hash codes for LM_LIGHTWEIGHT #16603
Conversation
Testing
|
👋 Welcome back aboldtch! 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.
This is great! I've done something like that in my original LW-locking PR, but then ripped it out to keep it simpler. Never got around to re-do it. Changes look good to me!
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.
Seems reasonable - though more complex than I had envisaged. One query below and a change requested for the test.
Thanks
test/hotspot/jtreg/runtime/whitebox/TestWBDeflateIdleMonitors.java
Outdated
Show resolved
Hide resolved
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.
Noting further from me. Runtime changes look good. Best to get a compiler dev to okay the C2 changes.
Thanks
if (LockingMode == LM_LIGHTWEIGHT) { | ||
// check if monitor | ||
__ testptr(result, markWord::monitor_value); | ||
__ jcc(Assembler::notZero, slowCase); | ||
} else { |
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 needed for other platforms? Or will that be done with other bugs or sub-tasks?
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 only found that x86 and 32bit arm does this in the shared runtime. I can create a jbs entry for arm. If it is the case that other platform do this for C1, then I cannot find where.
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.
Thumbs up. I have a couple of editorial comments, but I think that's it.
I did a review of the C2 changes and I don't see anything obviously wrong,
but having a C2 reviewer would be very, very useful.
This needs additional testing. I recommend Tier{1,2,3} on all the usual Oracle
platforms. Tier{4,5,6} would catch the uses of hash code stuff in more stress
related configs by the Serviceability tests.
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.
Compiler changes look good and in-line with the runtime changes.
Co-authored-by: Tobias Hartmann <tobias.hartmann@oracle.com>
The parent pull request that this pull request depends on has now been integrated and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout JDK-8319773
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push |
@xmas92 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 no new commits pushed to the ➡️ 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.
I've re-reviewed the changes from v03 -> v08.
Thumbs up with what you currently have. There's still one open query
in FastHashCode
about whether the VMThread can get in there
during JVM/TI tagging... It may be best to file a follow up bug for
chasing down that detail and possibly addressing it... Or you could
address it with one more change in this PR...
@xmas92 This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
The last merge was on 2023.12.04 so I'll review again after this PR is merged |
Ran tier1-5 all Oracle platforms with both LM_LEGACY and LM_LIGHTWEIGHT after the merge. |
/integrate |
Going to push as commit 65a0672.
Your commit was automatically rebased without conflicts. |
LM_LIGHTWEIGHT only uses the lock bits for its locking. This leaves the hashCode bits free when a monitor is not inflated. So instead of inflating when installing the hashCode on a fast locked object it can simply use the hashCode bits in the markWord.
The mark word transitions Unlocked (0b01) <=> Locked (0b00) are done by retrying the CAS if it fails due to non-lock bit changes.
The mark word transitions Monitor (0b10) <=> Locked/Unlocked (0b0X) are the same as before, inflation already handles hash codes. This change does not interact with the mark word if it is in a Monitor (0b10) state, so the strong CAS which is used for deflation are still valid, and will not fail to any other reason than the cooperative race to help transition the mark word during deflation.
This is dependent on JDK-8319778 simply because JDK-8319797 is dependent on both this and JDK-8319778.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/16603/head:pull/16603
$ git checkout pull/16603
Update a local copy of the PR:
$ git checkout pull/16603
$ git pull https://git.openjdk.org/jdk.git pull/16603/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 16603
View PR using the GUI difftool:
$ git pr show -t 16603
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/16603.diff
Webrev
Link to Webrev Comment