jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest JVMTI_THREAD_STATE_WAITING_INDEFINITELY JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT some mandatory bits are not set about openj9

[babsingh]

• It seems related to #19076.
• #19186 is the potential fix which was merged an hour after the failing builds were launched.
• @fengxue-IS Can you please launch appropriate grinders to confirm that #19186 fixes this failure?

[babsingh]

Another note: the original failure reported in this issue has been resolved by #19186.

[pshipton]

@babsingh fyi

[fengxue-IS]

20x Grinder on zlinux
2/20 failed, looking into the failures

[fengxue-IS]

Test failed with the patch included are all due to IN_NATIVE being set on the vthread. looking into the changeset to see what could cause this

[fengxue-IS]

New failure output with patch included:

[2024-03-21T16:05:40.239Z] >>JVMTI_THREAD_STATE_RUNNABLE
[2024-03-21T16:05:40.239Z] Thread VirtualThread[#24]/runnable@ForkJoinPool-1-worker-1
[2024-03-21T16:05:40.239Z] cthread state(91):  ALIVE WAITING WAITING_INDEFINITELY
[2024-03-21T16:05:40.239Z] vthread state(400005):  ALIVE RUNNABLE IN_NATIVE
[2024-03-21T16:05:40.239Z]   ERROR: some unexpected bits are set (400000):  IN_NATIVE
[2024-03-21T16:05:40.239Z]   expected 'strong' state (5):  ALIVE RUNNABLE
[2024-03-21T16:05:40.239Z]   expected 'weak' state (0): <none>
[2024-03-21T16:05:40.239Z] suspend cthread
[2024-03-21T16:05:40.239Z] cthread state(100091):  ALIVE WAITING WAITING_INDEFINITELY SUSPENDED
[2024-03-21T16:05:40.239Z] vthread state(400005):  ALIVE RUNNABLE IN_NATIVE
[2024-03-21T16:05:40.239Z]   ERROR: some unexpected bits are set (400000):  IN_NATIVE
[2024-03-21T16:05:40.239Z]   expected 'strong' state (5):  ALIVE RUNNABLE
[2024-03-21T16:05:40.239Z]   expected 'weak' state (0): <none>
[2024-03-21T16:05:40.239Z] suspend vthread
[2024-03-21T16:05:40.239Z] cthread state(100091):  ALIVE WAITING WAITING_INDEFINITELY SUSPENDED
[2024-03-21T16:05:40.239Z] vthread state(500005):  ALIVE RUNNABLE SUSPENDED IN_NATIVE
[2024-03-21T16:05:40.239Z]   ERROR: some unexpected bits are set (400000):  IN_NATIVE
[2024-03-21T16:05:40.239Z]   expected 'strong' state (100005):  ALIVE RUNNABLE SUSPENDED
[2024-03-21T16:05:40.239Z]   expected 'weak' state (0): <none>
[2024-03-21T16:05:40.239Z] resume cthread
[2024-03-21T16:05:40.239Z] cthread state(91):  ALIVE WAITING WAITING_INDEFINITELY
[2024-03-21T16:05:40.239Z] vthread state(500005):  ALIVE RUNNABLE SUSPENDED IN_NATIVE
[2024-03-21T16:05:40.239Z]   ERROR: some unexpected bits are set (400000):  IN_NATIVE
[2024-03-21T16:05:40.239Z]   expected 'strong' state (100005):  ALIVE RUNNABLE SUSPENDED
[2024-03-21T16:05:40.239Z]   expected 'weak' state (0): <none>
[2024-03-21T16:05:40.239Z] interrupt vthread
[2024-03-21T16:05:40.239Z] cthread state(91):  ALIVE WAITING WAITING_INDEFINITELY
[2024-03-21T16:05:40.239Z] vthread state(700005):  ALIVE RUNNABLE SUSPENDED INTERRUPTED IN_NATIVE
[2024-03-21T16:05:40.239Z]   ERROR: some unexpected bits are set (400000):  IN_NATIVE
[2024-03-21T16:05:40.239Z]   expected 'strong' state (300005):  ALIVE RUNNABLE SUSPENDED INTERRUPTED
[2024-03-21T16:05:40.239Z]   expected 'weak' state (0): <none>
[2024-03-21T16:05:40.239Z] resume vthread
[2024-03-21T16:05:40.239Z] <<JVMTI_THREAD_STATE_RUNNABLE - FAILED

[babsingh]

https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html

• JVMTI_THREAD_STATE_IN_NATIVE: Thread is in native code--that is, a native method is running which has not called back into the VM or Java programming language code.
• See the thread state rules in https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#GetThreadState.
  Having IN_NATIVE in the thread state is considered valid as per the JVMTI spec.
• This behaviour is seen because our new behaviour allows a virtual thread to suspend in the middle of the mount/unmount phases

[fengxue-IS]

The stacktrace of the failing vthread:

<1420c00> 	!j9method 0x00000000012B6590   jdk/internal/misc/Unsafe.unpark(Ljava/lang/Object;)V
<1420c00> 	!j9method 0x00000000012F0830   java/util/concurrent/locks/LockSupport.unpark(Ljava/lang/Thread;)V
<1420c00> 	!j9method 0x0000000001333F70   java/util/concurrent/locks/AbstractQueuedSynchronizer.signalNext(Ljava/util/concurrent/locks/AbstractQueuedSynchronizer$Node;)V
<1420c00> 	!j9method 0x00000000013341B0   java/util/concurrent/locks/AbstractQueuedSynchronizer.releaseShared(I)Z
<1420c00> 	!j9method 0x0000000001484730   java/util/concurrent/CountDownLatch.countDown()V
<1420c00> 	!j9method 0x000000000145BB70   GetThreadStateMountedTest.lambda$runnable$0(Ljava/util/concurrent/CountDownLatch;[Z)V
<1420c00> 	!j9method 0x000000000145C4F0   GetThreadStateMountedTest$$Lambda/0x0000000093fa1a10.run()V
<1420c00> 	!j9method 0x000000000145BAB0   GetThreadStateMountedTest.lambda$createPinnedVThread$6(Ljava/lang/Object;Ljava/lang/Runnable;)V
<1420c00> 	!j9method 0x000000000145C7F0   GetThreadStateMountedTest$$Lambda/0x0000000093fa1bc0.run()V
<1420c00> 	!j9method 0x00000000012DBC80   java/lang/Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V
<1420c00> 	!j9method 0x00000000012F7478   java/lang/VirtualThread.run(Ljava/lang/Runnable;)V
<1420c00> 	!j9method 0x00000000014ADAF0   java/lang/VirtualThread$VThreadContinuation$1.run()V
<1420c00> 	!j9method 0x0000000001306360   jdk/internal/vm/Continuation.enter(Ljdk/internal/vm/Continuation;)V
<1420c00> 	                        JNI call-in frame
<1420c00> 	                        Native method frame

Looking at the test failure it self, this is not a blocker or functional incorrectness.
As jdk/internal/misc/Unsafe.unpark is implemented as an JNI call in OpenJ9, if the unparked thread called getThreadState before the vthread returned from unpark() call. We will get this error.
This test failure is due to impl differences between RI and OpenJ9, which can either be fixed by updating test to use a spin wait mechanism instead of CountDownLatch.
An INL/fastJNI for unpark which retains VMAccess can also be added on the VM side, but that would need more discussion on the impact.

Based on this, I will continue with backport of #19076 to 0.44

[pshipton]

Based on this, I will continue with backport of #19091 to 0.44

Pls make this happen asap today.

[tajila]

The latest is that this is a test issue. We can modify the test to address this.