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
8274298: JFR Thread Sampler thread must not acquire malloc lock after suspending a thread because of possible deadlock #5977
Conversation
|
Webrevs
|
@mgronlun 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! |
@mgronlun 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 64 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.
|
|
/integrate |
Going to push as commit 965ea8d.
Your commit was automatically rebased without conflicts. |
Greetings,
JDK-8233705 introduced a means to only iterate the incrementally tagged Klasses, instead of the entire set of Klasses in the JVM, as part of serializing metadata information. The newly tagged Klasses are enqueued onto a thread-local buffer using a load barrier. If the buffer runs out of space, a new buffer is accommodated, either from a free list or via a new allocation.
This is problematic for the JfrThreadSampler because the thread it has suspended could hold the malloc lock. For example, this could be the case if the suspended thread was in the process of deoptimization. The Deoptimization::UnrollBlock is a CHeapObj, and the vframes arrays use the NEW_C_HEAP_ARRAY macro.
The solution to this problem is to explicitly monitor the size of the thread-local buffer of the JfrThreadSampler thread, and pre-emptively renew it before thread suspension.
Testing: jdk_jfr, stress testing
Thanks
Markus
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5977/head:pull/5977
$ git checkout pull/5977
Update a local copy of the PR:
$ git checkout pull/5977
$ git pull https://git.openjdk.java.net/jdk pull/5977/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 5977
View PR using the GUI difftool:
$ git pr show -t 5977
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5977.diff