-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8306774: Make runtime/Monitor/GuaranteedAsyncDeflationIntervalTest.java more reliable #13634
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 shade! 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.
LGTM. Why did you steer away from the i-hash solution though, I thought that was rather neat.
@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 12 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 |
Previous version of this PR used the take-IHC-while-locked trick to inflate the monitors, but I figured it would not work after JDK-8291555: Implement alternative fast-locking scheme is here, and would quite probably be even less reliable as Lilliput progresses towards off-side IHC table. |
Hmmm... I don't remember seeing anything in JDK-8291555 that would break 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 like a reasonable fix so thumbs up.
I'm testing in Mach5 now.
test/hotspot/jtreg/runtime/Monitor/GuaranteedAsyncDeflationIntervalTest.java
Outdated
Show resolved
Hide resolved
Mach5 Tier1 testing passed. It doesn't look like the test is |
Perhaps I was too cautious about this. I figured that the practical reason to inflate the stack-locked object when IHC is requested is to deal with various races about the IHC installation in the displaced header. And since JDK-8291555 changes the stack-locking to not replace the header fully (only changing a bit, AFAIU), then IHC installation becomes much easier. But after reading the description again, I think JDK-8291555 only takes care of IHC on fastpath, i.e. when it is already installed. So take-IHC-while-locked might still work. Still, I don't feel quite safe with relying on it, because it seems (famous last words) an easy future change to allow IHC installation into stack-locked object header after JDK-8291555, and I think there is a tentative plan to move IHC out of the header completely with 32-bit headers, which would make inflation even less of the practical behavior. So I believe |
Thank you! I'll re-run some local testing and then integrate. |
Local testing looks good. GHAs look good. I am integrating now. /integrate |
Going to push as commit 9ad6dc8.
Your commit was automatically rebased without conflicts. |
As seen in some CI runs, doing
Object.wait(1)
to inflate 10K monitors can take quite a while. One of the test cases implicitly relies on threshold heuristics kicking in before the guaranteed interval of 5 seconds expires. Even if we wait for 1ms for eachwait
call, we only inflate 5K monitors in those 5 seconds. Which is okay for 5s and 10% threshold test, which would fire after about 1K monitors inflated. But we can also stall for longer -- becausewait(1)
is not guaranteed to return in 1ms, subject to locking granularity -- which means we can inflate less that 1K monitors, which would mean the threshold heuristics would not fire.This fix strengthens the test in two ways:
wait(1)
.This also makes the test faster.
@dcubed-ojdk, you might want to run this through your CI to see if it fixes the test troubles.
Additional testing:
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13634/head:pull/13634
$ git checkout pull/13634
Update a local copy of the PR:
$ git checkout pull/13634
$ git pull https://git.openjdk.org/jdk.git pull/13634/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 13634
View PR using the GUI difftool:
$ git pr show -t 13634
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13634.diff
Webrev
Link to Webrev Comment