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
8277631: ZGC: CriticalMetaspaceAllocation asserts #6520
Conversation
|
Webrevs
|
@fisk This change now passes all automated pre-integration checks. 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 34 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.
|
Just a comment but it always concerns me that if we have to manually add a TBIVM when using a non-safepoint-checking lock then the lock is mis-classified as a non-safepoint-checking one! :(
That aside changes look fine. A few grammatical nits in the test.
Thanks,
David
for (;;) { | ||
ThreadBlockInVM tbivm(JavaThread::current()); |
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.
Can't you move the TBIVM outside of the loop now that it is always created?
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.
Just a comment but it always concerns me that if we have to manually add a TBIVM when using a non-safepoint-checking lock then the lock is mis-classified as a non-safepoint-checking one! :(
That aside changes look fine. A few grammatical nits in the test.
Thanks, David
Thanks for the review David. I fixed your nits.
I agree that this lock should preferably have been a safepoint checking lock. In fact, it was a safepoint checking lock when I wrote the code. But that was before we changed the locking rules so that whether we do safepoint checking or not is a function of the rank. After that, this lock has become constrained to the current low rank by the current set of other locks, and by being that low ish rank, it is not allowed to safepoint check, unless I move a bunch of other lock ranks around, and figure out if it's okay for those locks to start safepoint checking as well, which isn't entirely obvious.
So this lock might be a case where those new rules end up being a bit awkward, and have lead this code to do manual transitions to blocked instead, as an escape hatch from the asserts.
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.
Ah! I forgot about the rank changes that forced this dichotomy.
* @summary converted from VM Testbase gc/gctests/LoadUnloadGC. | ||
* VM Testbase keywords: [gc, stress, stressopt, nonconcurrent, monitoring] | ||
* VM Testbase readme: | ||
* In this test a 1000 classes are loaded and unloaded in a loop. |
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.
nit: /a 1000/1000/
* VM Testbase readme: | ||
* In this test a 1000 classes are loaded and unloaded in a loop. | ||
* Class0 gets loaded which results in Class1 getting loaded and so on all | ||
* the way uptill class1000. The classes should be unloaded whenever a |
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.
nit: /uptill/up until/ or /up to/
* Class0 gets loaded which results in Class1 getting loaded and so on all | ||
* the way uptill class1000. The classes should be unloaded whenever a | ||
* garbage collection takes place because their classloader is made unreachable | ||
* at the end of the each loop iteration. The loop is repeated 1000 times. |
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.
nit: s/the each/each/
/integrate |
Going to push as commit 3034ae8.
Your commit was automatically rebased without conflicts. |
The MetaspaceCritical_lock is a non-safepoint checking lock. That implies that the allow VM block flag is true. That implies that taking that lock takes a NoSafepointVerifier. That causes an assert to fire when MetaspaceCriticalAllocation::wait_for_purge transitions to blocked with ThreadBlockInVM while holding the lock. The fix is to move the locker inside of the ThreadBlockInVM.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6520/head:pull/6520
$ git checkout pull/6520
Update a local copy of the PR:
$ git checkout pull/6520
$ git pull https://git.openjdk.java.net/jdk pull/6520/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 6520
View PR using the GUI difftool:
$ git pr show -t 6520
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6520.diff