On Mon, 20 Nov 2023 00:59:35 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> The stack trace of current thread (where the assert was fired) can explain
>> what is going on a little bit:
>>
>> Current thread (0x00007f93f8043d00): JavaThread "ForkJoinPool-1-worker-1"
>> daemon [_thread_in_vm, id=16779,
>> stack(0x00007f948a597000,0x00007f948a697000) (1024K)]
>>
>> Stack: [0x00007f948a597000,0x00007f948a697000], sp=0x00007f948a6949e0,
>> free space=1014k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
>> code)
>> V [libjvm.so+0x117937d]
>> JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState*)+0x45d
>> (jvmtiEventController.cpp:402)
>> V [libjvm.so+0x1179520]
>> JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState*)
>> [clone .part.0]+0x190 (jvmtiEventController.cpp:632)
>> V [libjvm.so+0x117a1e1]
>> JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x351
>> (jvmtiEventController.cpp:1174)
>> V [libjvm.so+0x117e608]
>> JvmtiExport::get_jvmti_thread_state(JavaThread*)+0x98 (jvmtiExport.cpp:424)
>> V [libjvm.so+0x118a86c] JvmtiExport::post_field_access(JavaThread*,
>> Method*, unsigned char*, Klass*, Handle, _jfieldID*)+0x6c
>> (jvmtiExport.cpp:2214)
>> V [libjvm.so+0x118b3a1] JvmtiExport::post_field_access_by_jni(JavaThread*,
>> oop, Klass*, _jfieldID*, bool)+0x321 (jvmtiExport.cpp:2202)
>> V [libjvm.so+0x118b4e9] JvmtiExport::jni_GetField_probe(JavaThread*,
>> _jobject*, oop, Klass*, _jfieldID*, bool)+0x79 (jvmtiExport.cpp:2168)
>> V [libjvm.so+0xf83847] jni_GetStaticBooleanField+0x257 (jni.cpp:2047)
>> C [libfieldacc02.so+0x379b] Java_fieldacc02_check+0x6b (jni.h:1546)
>> j fieldacc02.check(Ljava/lang/Object;)I+0
>> j fieldacc02.lambda$testVirtualThread$0()V+12
>> j fieldacc02$$Lambda+0x00007f943b001428.run()V+0
>> j java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5
>> java.base@22-internal
>> j java.lang.VirtualThread.run(Ljava/lang/Runnable;)V+66
>> java.base@22-internal
>> j java.lang.VirtualThread$VThreadContinuation$1.run()V+8
>> java.base@22-internal
>> j jdk.internal.vm.Continuation.enter0()V+4 java.base@22-internal
>> j jdk.internal.vm.Continuation.enter(Ljdk/internal/vm/Continuation;Z)V+1
>> java.base@22-internal
>> J 124
>> jdk.internal.vm.Continuation.enterSpecial(Ljdk/internal/vm/Continuation;ZZ)V
>> java.base@22-internal (0 bytes) @ 0x00007f94c7cdf744
>> [0x00007f94c7cdf5e0+0x0000000000000164]
>> j jdk.internal.vm.Continuation.run()V+122 java.base@22-internal
>> j java.lang.VirtualThread.runContinuation()V+70 java.base@22-internal
>> j java.lang.VirtualThread$$Lambda+0x00007f943b049...
>
> Just to re-iterate what Dan was saying, the TLH is only of use if you are
> accessing threads known to be included in the TLH.
The issue occurred to be with the current thread which has to be safe to access
without a TLH.
However, there is this guarantee in the `Hanshake::execute()`:
void Handshake::execute(HandshakeClosure* hs_cl, ThreadsListHandle* tlh,
JavaThread* target) {
. . .
guarantee(target != nullptr, "must be");
if (tlh == nullptr) {
guarantee(Thread::is_JavaThread_protected_by_TLH(target),
"missing ThreadsListHandle in calling context.");
This guarantee fired for current thread is a source of confusion and mistakes.
Would it be a right thing to correct it?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16686#discussion_r1398993572
