-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
8343132: Remove temporary transitions from Virtual thread implementation #21735
Conversation
👋 Welcome back alanb! A progress list of the required criteria for merging this PR into |
@AlanBateman 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 2 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
@AlanBateman The following labels 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 lists. 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.
The fix looks good to me. It is important and nice simplification.
The JVMTI part is strait forward.
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 to me. Thanks for removing this.
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.
Hotspot cleanup looks great! It is really good to see this temporary transition logic go away.
@@ -811,30 +810,28 @@ private static boolean traceVirtualThreadLocals() { | |||
} | |||
|
|||
/** | |||
* Print a stack trace if the current thread is a virtual thread. | |||
* Print the print stack of the current thread, skipping the printStackTrace frame. |
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.
* Print the print stack of the current thread, skipping the printStackTrace frame. | |
* Print the stack of the current thread, skipping the printStackTrace frame. |
timeoutTask = schedule(this::unpark, parkTimeout, NANOSECONDS); | ||
setState(newState = TIMED_PARKED); |
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 to be clear here, if the timeout expires before we can call setState
, the unpark is basically a no-op, and we will see that we have been unparked at line 541 and set the state correctly to UNPARKED.
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.
Yes, and same thing if unparked by some other thread while the target thread is parking. We have several tests that bash on this.
// ExecutorService::execute may consume parking permit | ||
LockSupport.unpark(Thread.currentThread()); |
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 seems a bit odd - why would the current thread need to unpark itself? Why should it have a park permit available here?
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.
In this test, Scheduler.execute method will consume the current thread's parking permit when there is contention on the queue. In a well behaved system, all usages of park will first test some condition before parking. This test doesn't do this, hence it created the scenario where parking after unparking might hang. Previous discussion in loom/pull/59. There is no support exposed for doing custom schedulers at this time but this is the type of thing that comes up so we kept the test.
/integrate |
Going to push as commit dee0982.
Your commit was automatically rebased without conflicts. |
@AlanBateman Pushed as commit dee0982. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
This is an update to the Virtual thread implementation that we'd like to integrate in advance of JEP 491.
The update removes the use of "temporary transitions", basically cases where the thread identity switches to the carrier thread to do something in the context of the carrier while a virtual thread is mounted. These cases create complexity for JVMTI and observability tools. It has also attracted attention in the review of the JEP 491 implementation as the object monitor changes have to deal with the possibility of entering monitors while in this state. There are 3 usages changes:
The changes means that notifyJvmtiHideFrames, its intrinsic, and the JVMTI "tmp VTMS_transition" bit go away.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/21735/head:pull/21735
$ git checkout pull/21735
Update a local copy of the PR:
$ git checkout pull/21735
$ git pull https://git.openjdk.org/jdk.git pull/21735/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 21735
View PR using the GUI difftool:
$ git pr show -t 21735
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/21735.diff
Using Webrev
Link to Webrev Comment