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
8297168: Provide a bulk OopHandle release mechanism with the ServiceThread #11254
Conversation
👋 Welcome back dholmes! A progress list of the required criteria for merging this PR into |
@dholmes-ora The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
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.
Looks fine!
@dholmes-ora 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 57 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 |
Thanks for the review @robehn . |
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.
So the choice was moving OopHandleList to a header file, or telling ServiceThread about these fields.
Since nothing else calls add_oop_handle_release , I really would have picked the former, and moved the declaration of OopHandleList to javaThread.hpp, constructed the list and passed it to the service thread in javathread.cpp.
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'm still not happy that ServiceThread knows all about JavaThread's fields that need to be cleared. But all of the OopHandleList code that's in serviceThread.cpp should be moved to javaThread.cpp. And two new functions added to JavaThread for ServiceThread to call (has_oop_handles_to_release and release_oop_handles).
I still think it's better since JavaThread is the only thing that has the necessity of deferred release.
Thanks for looking at this @coleenp. As I said I didn't think ServiceThread knowing the details was an issue because ServiceThread is-a JavaThread. But sure I can move everything to JavaThread instead if that is preferable. |
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 good! Thank you.
Thanks for the review @coleenp ! |
Going to push as commit a6c418e.
Your commit was automatically rebased without conflicts. |
@dholmes-ora Pushed as commit a6c418e. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
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!
private: | ||
// List of OopHandles to be released - guarded by the Service_lock. | ||
static OopHandleList* _oop_handle_list; | ||
// Add our OopHandles to the list for the service thread to release. |
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/service thread/ServiceThread/
ServiceThread::add_oop_handle_release(_vthread); | ||
ServiceThread::add_oop_handle_release(_jvmti_vthread); | ||
ServiceThread::add_oop_handle_release(_extentLocalCache); | ||
// Enqueue OopHandles for release by the service thread. |
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/service thread/ServiceThread/
@@ -52,7 +52,6 @@ class ServiceThread : public JavaThread { | |||
|
|||
// Add event to the service thread event queue. |
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/service thread/ServiceThread/
Not your typo, but since you're close by...
Sorry I didn't submit my review on-time... |
No problem Dan - thanks for taking a look. I think it is okay to talk about the "service thread" as a concept, just as we talk about "compiler threads" and "gc threads" without always using the classname |
When a
JavaThread
terminates it has to release allOopHandles
that it uses. This can't be done by the thread itself due to timing issues, so it is handed-off to theServiceThread
to do it - ref JDK-8244997.Initially there was only one
OopHandle
to handle - that of thethreadObj
, but since Loom there are another 3OopHandles
to process. The existing logic does the hand-off oneOopHandle
at a time but that is a potential synchronization bottleneck because each hand-off acquires theServiceLock
, enqueues theOopHandle
, issues a notify to (potentially) wakeup theServiceThread
and then releases theServiceLock
. This can lead to high contention on theServiceLock
and also bad scheduling interactions with theServiceThread
.This PR contains two commits. The first simply changes the API so that we pass the target
JavaThread
so that all 4OopHandles
can be extracted in one call. The second commit looks at streamlining things further by consolidating into a singleOopHandleList
instance.As
ServiceThread is a subclass of
JavaThread` I wasn't concerned about it having detailed knowledge of the JavaThread implementation.Testing:
Thanks.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/11254/head:pull/11254
$ git checkout pull/11254
Update a local copy of the PR:
$ git checkout pull/11254
$ git pull https://git.openjdk.org/jdk pull/11254/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 11254
View PR using the GUI difftool:
$ git pr show -t 11254
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/11254.diff