Skip to content
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.

Sign up for GitHub

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

Jump to bottom

JDK21 serviceability_jvmti SuspendResumeAll RuntimeException unexpected status: 2 #18370

Closed
babsingh opened this issue Oct 28, 2023 · 1 comment
Closed

JDK21 serviceability_jvmti SuspendResumeAll RuntimeException unexpected status: 2 #18370

babsingh opened this issue Oct 28, 2023 · 1 comment
Assignees
@babsingh
Labels
comp:jvmti comp:vm jdk21 project:loom Used to track Project Loom related work test failure
Milestone
Java 21 (0.42)

Comments

@babsingh
Copy link
Contributor

babsingh commented Oct 28, 2023 •
edited
Loading

Failure link

JDK21 x86-64_mac(mac11x64rt04)

10:57:25  java version "21.0.1-beta" 2023-10-17
10:57:25  IBM Semeru Runtime Certified Edition 21.0.1+12-202310261403 (build 21.0.1-beta+12-202310261403)
10:57:25  Eclipse OpenJ9 VM 21.0.1+12-202310261403 (build master-66e3fd1da, JRE 21 Mac OS X amd64-64-Bit Compressed References 20231026_22 (JIT enabled, AOT enabled)
10:57:25  OpenJ9   - 66e3fd1da
10:57:25  OMR      - 071c0c25b
10:57:25  JCL      - c06eaf638 based on jdk-21.0.1+12)

Optional info

Failure output (captured from console output)

java version "21.0.1-beta" 2023-10-17
IBM Semeru Runtime Certified Edition 21.0.1+12-202310261403 (build 21.0.1-beta+12-202310261403)
Eclipse OpenJ9 VM 21.0.1+12-202310261403 (build master-66e3fd1da, JRE 21 Mac OS X amd64-64-Bit Compressed References 20231026_22 (JIT enabled, AOT enabled)
OpenJ9   - 66e3fd1da
OMR      - 071c0c25b
JCL      - c06eaf638 based on jdk-21.0.1+12)

[2023-10-26T15:00:50.188Z] variation: Mode650
[2023-10-26T15:00:50.188Z] JVM_OPTIONS:  -XX:-UseCompressedOops 

[2023-10-26T15:03:11.620Z] TEST: serviceability/jvmti/vthread/SuspendResumeAll/SuspendResumeAll.java#no-vmcontinuations

[2023-10-26T15:03:11.621Z] STDERR:
[2023-10-26T15:03:11.621Z] java.lang.RuntimeException: FAILED: unexpected status: 2
[2023-10-26T15:03:11.621Z] 	at SuspendResumeAll.main(SuspendResumeAll.java:78)
[2023-10-26T15:03:11.621Z] 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
[2023-10-26T15:03:11.621Z] 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
[2023-10-26T15:03:11.621Z] 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
[2023-10-26T15:03:11.621Z] 	at java.base/java.lang.Thread.run(Thread.java:1595)

[2023-10-26T15:03:30.804Z] serviceability_jvmti_j9_1_FAILED
@babsingh babsingh changed the title JDK21 serviceability_jvmti SuspendResumeAll RuntimeException: FAILED: unexpected status: 2 JDK21 serviceability_jvmti SuspendResumeAll RuntimeException unexpected status: 2 Oct 28, 2023
@babsingh babsingh added comp:jvmti comp:vm test failure jdk13 project:loom Used to track Project Loom related work jdk21 and removed jdk13 labels Oct 28, 2023
@babsingh babsingh mentioned this issue Oct 28, 2023
Closed
@babsingh babsingh self-assigned this Oct 28, 2023
@pshipton pshipton added this to the Java 21 (0.42) milestone Oct 28, 2023
babsingh added a commit to babsingh/openj9 that referenced this issue Nov 8, 2023
@babsingh
Re-fetch objects after VM access is released and reacquired
cb4f50b 
Stale objects can manifest many issues. In this case, stale objects
cause complex and intermittent synchronization issues.

Related: eclipse-openj9#17865
Related: eclipse-openj9#17869
Related: eclipse-openj9#18370

Signed-off-by: Babneet Singh <[email protected]>
This was referenced Nov 8, 2023
Merged
Merged
babsingh added a commit to babsingh/openj9 that referenced this issue Nov 9, 2023
@babsingh
Re-fetch objects after VM access is released and reacquired
a1cdacf 
Stale objects can manifest many issues. In this case, stale objects
cause complex and intermittent synchronization issues.

Related: eclipse-openj9#17865
Related: eclipse-openj9#17869
Related: eclipse-openj9#18370

Signed-off-by: Babneet Singh <[email protected]>
@babsingh babsingh mentioned this issue Nov 10, 2023
Merged
@babsingh babsingh mentioned this issue Nov 13, 2023
Closed
babsingh added a commit to babsingh/openj9 that referenced this issue Nov 13, 2023
@babsingh
Spin during VirtualThread MountBegin and UnmountBegin
feac356 
Currently, the halt flag is set in VirtualThread MountEnd if a virtual
thread is suspended via JVMTI, and in VirtualThread UnmountEnd if a
carrier thread is suspended via JVMTI.

In the above approach, the halt flag is set too late. As soon as the
continuation swaps the J9VMThread context, the thread begins execution
and is capable of triggering JVMTI events.

To avoid the above issue, the above steps are moved into VirtualThread
MountBegin and UnmountBegin. This prevents the continuation to swap
the J9VMThread context.

Currently, the halt flag is set without invoking
exitVThreadTransitionCritical. This prevents JVMTI to resume the halted
thread and cause a hang. The new approach spins, invokes
exitVThreadTransitionCritical  and releases VM access to allow JVMTI to
resume the suspended thread.

The better approach will be to fail mount if the thread is suspended
and retry later. Currently, his approach cannot be implemented because
VirtualThread.java does not support this approach.

Related: eclipse-openj9#17865
Related: eclipse-openj9#17869
Related: eclipse-openj9#18370

Signed-off-by: Babneet Singh <[email protected]>
babsingh added a commit to babsingh/openj9 that referenced this issue Nov 14, 2023
@babsingh
Update the fully mounted check in JVMTI Suspend/Resume Thread
1cd50dd 
During JVMTI suspend/resume thread operations, the current check to
determine if a thread is fully mounted is flaky. It depends on
J9VMThread->theadObject which might change after getVMThread due to
Java level changes, which are accepted as-is from the RI.

The check to determine if a thread is fully mounted is moved into
getVMThread. The check is updated to use the continuation state, which
is more stable since the Continuation implementation is maintained
within OpenJ9.

Related: eclipse-openj9#17865
Related: eclipse-openj9#17869
Related: eclipse-openj9#18370

Signed-off-by: Babneet Singh <[email protected]>
@babsingh babsingh mentioned this issue Nov 15, 2023
Merged
babsingh added a commit to babsingh/openj9 that referenced this issue Nov 16, 2023
@babsingh @fengxue-IS
Add JVMTI synchronization in JVM_VirtualThreadHideFrames
8a2b61e 
J9VMThread->threadObject can be modified between
JVM_VirtualThreadHideFrames's first invocation with hide=true and
second invocation with hide=false. Synchronization to prevent JVMTI
operations is acquired between these two invocations. This prevents
JVMTI functions to see an unstable J9VMThread->threadObject.

Related: eclipse-openj9#17865
Related: eclipse-openj9#17869
Related: eclipse-openj9#18370

Co-authored-by: Jack Lu <[email protected]>
Signed-off-by: Babneet Singh <[email protected]>
@babsingh
Copy link
Contributor Author

Fixed via

babsingh added a commit to babsingh/openj9 that referenced this issue Nov 20, 2023
@babsingh @fengxue-IS
Add JVMTI synchronization in JVM_VirtualThreadHideFrames
38907fd 
J9VMThread->threadObject can be modified between
JVM_VirtualThreadHideFrames's first invocation with hide=true and
second invocation with hide=false. Synchronization to prevent JVMTI
operations is acquired between these two invocations. This prevents
JVMTI functions to see an unstable J9VMThread->threadObject.

Related: eclipse-openj9#17865
Related: eclipse-openj9#17869
Related: eclipse-openj9#18370

Co-authored-by: Jack Lu <[email protected]>
Signed-off-by: Babneet Singh <[email protected]>
babsingh added a commit to babsingh/openj9 that referenced this issue Nov 20, 2023
@babsingh @fengxue-IS
Add JVMTI synchronization in JVM_VirtualThreadHideFrames
ecdbc7b 
J9VMThread->threadObject can be modified between
JVM_VirtualThreadHideFrames's first invocation with hide=true and
second invocation with hide=false. Synchronization to prevent JVMTI
operations is acquired between these two invocations. This prevents
JVMTI functions to see an unstable J9VMThread->threadObject.

Related: eclipse-openj9#17865
Related: eclipse-openj9#17869
Related: eclipse-openj9#18370

Co-authored-by: Jack Lu <[email protected]>
Signed-off-by: Babneet Singh <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@babsingh babsingh

Labels
comp:jvmti comp:vm jdk21 project:loom Used to track Project Loom related work test failure
Projects
None yet
Milestone
Java 21 (0.42)
Development

No branches or pull requests
2 participants
@babsingh @pshipton