Fix to handle suspend/resume of virtual/carrier threads #17350
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
JVMTI treats a virtual thread and its carrier thread as two separate threads. If JVMTI suspends a virtual thread, then its carrier thread should not be suspended and vice-versa. Similarly, if JVMTI resumes a virtual thread, then its carrier thread should not be resumed and vice-versa. In OpenJ9, currently, a mounted virtual thread and its carrier thread shared the same J9VMThread. The thread state is derived from the J9VMThread. Due to the sharing of the J9VMThread in the mounted state,if a mounted virtual thread is suspended, then the JVMTI functions will also reflect that its carrier thread is suspended. Currently, "isSuspendedByJVMTI" is the hidden field that holds the suspend status for the virtual thread only, now it made available for carrier thread too, i.e. the scope has changed from "java/lang/VirtualThread" to "java/lang/Thread" threads Also, it is renamed to "isSuspendedInternal" as this hidden field is not just specific to JVMTI. The following functions has changed to set/reset and verify "isSuspendedInternal" status for threads:- 1) SUSPEND THREAD:- suspendhelper.cpp:suspendThread: jvmtiThread.c:jvmtiSuspendResumeCallBack thread.cpp:Java_java_lang_Thread_suspendImpl ->In case of suspend the halt flag (J9_PUBLIC_FLAGS_HALT_THREAD_JAVA_SUSPEND) is set if the thread is mounted, i.e. threadObject == targetThread->threadObject in J9VMThread's publicFlags also the hidden field "isSuspendedInternal" set to a non-zero value for the thread instance in all cases regardless of thread being mounted or unmounted. ->If any of the public flags are already set, then the relevant failure message is assigned. 2) RESUME THREAD:- jvmtiThread.c:resumeThread: jvmtiThread.c:jvmtiSuspendResumeCallBack thread.cpp:Java_java_lang_Thread_resumeImpl ->In case of resume the halt flag (J9_PUBLIC_FLAGS_HALT_THREAD_JAVA_SUSPEND) is cleared if the thread is mounted, i.e. threadObject == targetThread->threadObject in J9VMThread's publicFlags also the hidden field "isSuspendedInternal" set to a zero value for the thread instance in all cases regardless of thread being mounted or unmounted. ->If any of the public flags are already set, then the relevant failure message is assigned. 3) GETSTATE:- jvmtiHelpers.c:getThreadState jvmtiHelpers.c:getVirtualThreadState ->The getThreadState function is changed in such a way that will verify the "isSuspendedInternal" filed to check the thread is suspend or not. The basic concept behind the new changes: [mounted + unmounted] set the "isSuspendedInternal" field [mounted] the halt flag is only modified if the thread object is stored in targetThread->threadObject [unmounted] Delay setting the halt flag until the thread mount. Related: eclipse-openj9#16689 Signed-off-by: Dipak Bagadiya dipak.bagadiya@ibm.com
dipak-bagadiya
force-pushed
the
vt_suspend_resume_final
branch
from
e426a39
to
4fa83c6
Compare
|
The personal build for JDK 8, 11, and 20 was triggered, and the list of known failures is listed below; no other failures were noticed.
The below failure appears to be known ones, but I did not find any open issue for the same reason, and it
|
|
jenkins test sanity,sanity.openjdk,extended.openjdk zlinux jdk20 |
|
jenkins test sanity,sanity.openjdk,extended.openjdk alinux64 jdk17 |
|
jenkins test sanity,sanity.openjdk,extended.openjdk win jdk20 |
babsingh
approved these changes
May 10, 2023
There was a problem hiding this comment.
https://openj9-jenkins.osuosl.org/job/Test_openjdk20_j9_extended.openjdk_x86-64_windows_Personal/2/testReport/
-----
https://openj9-jenkins.osuosl.org/job/Test_openjdk20_j9_extended.openjdk_s390x_linux_Personal/2/testReport/
Only noticed known and unrelated issues across the failing builds:
- JDK20 jdk/incubator/concurrent/ScopedValue/StressStackOverflow.java StressStackOverflow$TestFailureException: Unexpected value for ScopedValue #16965
- CryptoTests SunMSCAPI failing on Windows due to Access is denied #16710
- [Infra]
java.io.IOException: There is not enough space on the disk
The side effects seen in #17334 have been resolved.
dipak-bagadiya
added a commit
to dipak-bagadiya/aqa-tests
that referenced
this pull request
May 11, 2023
Test has been fixed by eclipse-openj9/openj9#17350 Signed-off-by: Dipak Bagadiya dipak.bagadiya@ibm.com
llxia
added a commit
to adoptium/aqa-tests
that referenced
this pull request
May 16, 2023
Test has been fixed by eclipse-openj9/openj9#17350 Signed-off-by: Dipak Bagadiya dipak.bagadiya@ibm.com Signed-off-by: Dipak Bagadiya dipak.bagadiya@ibm.com Co-authored-by: Lan Xia <Lan_Xia@ca.ibm.com>
This was referenced May 16, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
JVMTI treats a virtual thread and its carrier thread as two separate threads. If JVMTI suspends a virtual thread, then its carrier thread should not be suspended and vice-versa. Similarly, if JVMTI resumes a virtual thread, then its carrier thread should not be resumed and vice-versa.
In OpenJ9, currently, a mounted virtual thread and its carrier thread shared the same J9VMThread. The thread state is derived from the J9VMThread. Due to the sharing of the J9VMThread in the mounted state,if a mounted virtual thread is suspended, then the JVMTI functions will also reflect that its carrier thread is suspended.
Currently, "isSuspendedByJVMTI" is the hidden field that holds the suspend status for the virtual thread only, now it made available for carrier thread too, i.e. the scope has changed from "java/lang/VirtualThread" to "java/lang/Thread" threads Also, it is renamed to "isSuspendedInternal" as this hidden field is not just specific to JVMTI.
The following functions has changed to set/reset and verify "isSuspendedInternal" status for threads:-
SUSPEND THREAD:-
suspendhelper.cpp:suspendThread:
jvmtiThread.c:jvmtiSuspendResumeCallBack
thread.cpp:Java_java_lang_Thread_suspendImpl
->In case of suspend the halt flag
(J9_PUBLIC_FLAGS_HALT_THREAD_JAVA_SUSPEND) is set if the thread is mounted, i.e. threadObject == targetThread->threadObject in J9VMThread's publicFlags also the hidden field "isSuspendedInternal" set to a non-zero value for the thread instance in all cases regardless of thread being mounted or unmounted.
->If any of the public flags are already set, then the relevant failure message is assigned.
RESUME THREAD:-
jvmtiThread.c:resumeThread:
jvmtiThread.c:jvmtiSuspendResumeCallBack
thread.cpp:Java_java_lang_Thread_resumeImpl
->In case of resume the halt flag
(J9_PUBLIC_FLAGS_HALT_THREAD_JAVA_SUSPEND) is cleared if the thread is mounted, i.e. threadObject == targetThread->threadObject in J9VMThread's publicFlags also the hidden field "isSuspendedInternal" set to a zero value for the thread instance in all cases regardless of thread being mounted or unmounted.
->If any of the public flags are already set, then the relevant failure message is assigned.
GETSTATE:-
jvmtiHelpers.c:getThreadState
jvmtiHelpers.c:getVirtualThreadState
->The getThreadState function is changed in such a way that will verify the "isSuspendedInternal" filed to check the thread is suspend or not.
The basic concept behind the new changes:
[mounted + unmounted] set the "isSuspendedInternal" field
[mounted] the halt flag is only modified if the thread object is
stored in targetThread->threadObject
[unmounted] Delay setting the halt flag until the thread mount.
Related: #16689
Signed-off-by: Dipak Bagadiya dipak.bagadiya@ibm.com