Loom: VirtualThread suspend/resume support for JVMTI #15760
Assignees
Labels
Milestone
Comments
babsingh
added a commit
to babsingh/openj9
that referenced
this issue
Sep 17, 2022
Related: eclipse-openj9#15760 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
babsingh
added a commit
to babsingh/openj9
that referenced
this issue
Sep 20, 2022
This PR impacts the following JVMTI functions: - [Resume|Suspend]Thread; - [Resume|Suspend]ThreadList; - [Resume|Suspend]AllVirtualThreads; and - GetThreadState. The above functions have been either implemented or updated as per the JVMTI doc: https://download.java.net/java/early_access/jdk19/docs/specs/jvmti.html Other changes: - JVM_VirtualThread* functions acquire liveVirtualThreadListMutex first, and then VM access. This allows [Resume|Suspend]AllVirtualThreads to hold liveVirtualThreadListMutex without any hangs, where VM access is not released by the JVM_VirtualThread* functions and the JVMTI functions are trying to acquire VM access to suspend the threads. - For virtual threads, targetThread is non-null for PARKING and YIELDING states. getVirtualThreadState has been updated to use carrier thread's state whenever targetThread is non-null for a virtual thread. This correctly returns the JVMTI_THREAD_STATE_SUSPENDED flag for virtual threads. Related: eclipse-openj9#15760 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
babsingh
added a commit
to babsingh/openj9
that referenced
this issue
Sep 29, 2022
This PR impacts the following JVMTI functions: - [Resume|Suspend]Thread - [Resume|Suspend]ThreadList - [Resume|Suspend]AllVirtualThreads The above functions have been either implemented or updated as per the JVMTI doc: https://download.java.net/java/early_access/jdk19/docs/specs/jvmti.html Other changes: - Renamed liveVirtualThreadListMutex to virtualThreadListMutex. It is only used to handle the virtual thread list. - Added virtualThreadInspectorMutex. It is only used for virtual thread inspection. - virtualThreadInspectorMutex creates a critical section between JVM_VirtualThreadMountBegin-End and JVM_VirtualThreadUnmountBegin-End. - We should not wait on virtualThreadListMutex in the above critical section. Otherwise, there are chances of a deadlock. - If a thread is suspended while waiting on the monitor, then the monitor is released after waking up and before invoking internalEnterVMFromJNI, where the thread will be halted until resumed. After resuming, the monitor is acquired again. This helps avoid deadlocks. Related: eclipse-openj9#15760 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
babsingh
added a commit
to babsingh/openj9
that referenced
this issue
Sep 30, 2022
This PR impacts the following JVMTI functions: - [Resume|Suspend]Thread - [Resume|Suspend]ThreadList - [Resume|Suspend]AllVirtualThreads The above functions have been either implemented or updated as per the JVMTI doc: https://download.java.net/java/early_access/jdk19/docs/specs/jvmti.html Other changes: - Renamed liveVirtualThreadListMutex to virtualThreadListMutex. It is only used to handle the virtual thread list. - Added virtualThreadInspectorMutex. It is only used for virtual thread inspection. - virtualThreadInspectorMutex creates a critical section between JVM_VirtualThreadMountBegin-End and JVM_VirtualThreadUnmountBegin-End. - We should not wait on virtualThreadListMutex in the above critical section. Otherwise, there are chances of a deadlock. - If a thread is suspended while waiting on the monitor, then the monitor is released after waking up and before invoking internalEnterVMFromJNI, where the thread will be halted until resumed. After resuming, the monitor is acquired again. This helps avoid deadlocks. Related: eclipse-openj9#15760 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
babsingh
added a commit
to babsingh/openj9
that referenced
this issue
Oct 4, 2022
This PR impacts the following JVMTI functions: - [Resume|Suspend]Thread - [Resume|Suspend]ThreadList - [Resume|Suspend]AllVirtualThreads The above functions have been either implemented or updated as per the JVMTI doc: https://download.java.net/java/early_access/jdk19/docs/specs/jvmti.html Other changes: - Added boolean inspectingLiveVirtualThreadList to synchronize between [Resume|Suspend]AllVirtualThreads, JVM_VirtualThreadMountBegin-End and JVM_VirtualThreadUnmountBegin-End. - If a thread is suspended while waiting on the monitor, then the monitor is released after waking up and before invoking internalEnterVMFromJNI, where the thread will be halted until resumed. After resuming, the monitor is acquired again. This helps avoid deadlocks. - If JVMTI_VTHREAD_STATE_SUSPENDED is set in VirtualThread.state, then the Java code to process JVMTI_VTHREAD_STATE_SUSPENDED has been missed. The thread was blocked on JVM_VirtualThreadMountBegin while being suspended. In such a case, J9_PUBLIC_FLAGS_HALT_THREAD_JAVA_SUSPEND is set in currentThread->publicFlags at the end of mount and JVMTI_VTHREAD_STATE_SUSPENDED is removed from VirtualThread.state. This forces the thread to suspend instead of keep running after it has been suspended. Related: eclipse-openj9#15760 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
babsingh
added a commit
to babsingh/openj9
that referenced
this issue
Oct 11, 2022
This PR impacts the following JVMTI functions: - [Resume|Suspend]Thread - [Resume|Suspend]ThreadList - [Resume|Suspend]AllVirtualThreads The above functions have been either implemented or updated as per the JVMTI doc: https://download.java.net/java/early_access/jdk19/docs/specs/jvmti.html Other changes: - Added boolean inspectingLiveVirtualThreadList to synchronize between [Resume|Suspend]AllVirtualThreads, JVM_VirtualThreadMountBegin-End and JVM_VirtualThreadUnmountBegin-End. - If a thread is suspended while waiting on the monitor, then the monitor is released after waking up and before invoking internalEnterVMFromJNI, where the thread will be halted until resumed. After resuming, the monitor is acquired again. This helps avoid deadlocks. - Added hidden field isSuspendedByJVMTI in VirtualThread to track if the thread was suspended in JVMTI. If isSuspendedByJVMTI is non-zero, then J9_PUBLIC_FLAGS_HALT_THREAD_JAVA_SUSPEND is set in carrier J9VMThread's publicFlags while resetting isSuspendedByJVMTI to zero. During mount, this suspends the thread if the thread was unmounted while JVMTI suspended it. Related: eclipse-openj9#15760 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
|
Completed via #15903. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Need to support suspending and resuming when the thread object supplied to JVMTI API is an instance of VirtualThread.
For VirtualThread that is mounted to a carrier thread, it should be treated as a normal thread and uses the existing code path
For VirtualThread that has yielded, we should use the
VirtualThread.SUSPENDEDto prevent the thread from being scheduled by the scheduler (to be verified against spec requirement and RI behavior)Specs:
https://download.java.net/java/early_access/jdk19/docs/specs/jvmti.html#SuspendThread
https://download.java.net/java/early_access/jdk19/docs/specs/jvmti.html#SuspendThreadList
https://download.java.net/java/early_access/jdk19/docs/specs/jvmti.html#SuspendAllVirtualThreads
https://download.java.net/java/early_access/jdk19/docs/specs/jvmti.html#ResumeThread
https://download.java.net/java/early_access/jdk19/docs/specs/jvmti.html#ResumeThreadList
https://download.java.net/java/early_access/jdk19/docs/specs/jvmti.html#ResumeAllVirtualThreads
The text was updated successfully, but these errors were encountered: