RFR: 8308614: Enabling JVMTI ClassLoad event slows down vthread creation by factor 10 [v3]

[Serguei Spitsyn]

On Mon, 20 Nov 2023 00:59:35 GMT, David Holmes <dholmes at 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 at 22-internal
>> j  java.lang.VirtualThread.run(Ljava/lang/Runnable;)V+66 java.base at 22-internal
>> j  java.lang.VirtualThread$VThreadContinuation$1.run()V+8 java.base at 22-internal
>> j  jdk.internal.vm.Continuation.enter0()V+4 java.base at 22-internal
>> j  jdk.internal.vm.Continuation.enter(Ljdk/internal/vm/Continuation;Z)V+1 java.base at 22-internal
>> J 124  jdk.internal.vm.Continuation.enterSpecial(Ljdk/internal/vm/Continuation;ZZ)V java.base at 22-internal (0 bytes) @ 0x00007f94c7cdf744 [0x00007f94c7cdf5e0+0x0000000000000164]
>> j  jdk.internal.vm.Continuation.run()V+122 java.base at 22-internal
>> j  java.lang.VirtualThread.runContinuation()V+70 java.base at 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