RFR: 8296323: JVMTI can_support_virtual_threads not available for agents loaded into running VM [v4]

[Richard Reingruber]

On Mon, 21 Nov 2022 19:08:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiExport.cpp line 201:
>> 
>>> 199:   JvmtiVirtualThreadEventMark(JavaThread *thread) :
>>> 200:     JvmtiEventMark(thread) {
>>> 201:     if (thread->vthread() != NULL) {
>> 
>> Can this condition ever be false?
>
> Yes, this condition can be false for platform threads.

The [comment](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/javaThread.hpp#L88) suggests that `vthread()` cannot evaluate to NULL. Otherwise `Thread.currentThread()` would return null too.

I've experimented a little bit and found that `thread->vthread()` in fact can be NULL during initialization but then `thread->threadObj()` is also not yet initialized. E.g. in `Threads::initialize_java_lang_classes()` class events are generated before `create_initial_thread()` is reached. The constructor of `JvmtiClassEventMark` calls its parent class' constructor, that is `JvmtiVirtualThreadEventMark`,  with a not yet fully initialized initial thread.

I found that `jtreg:test/hotspot/jtreg:hotspot_serviceability` succeeds with `assert(thread->vthread() != NULL || thread->threadObj() == NULL, "");`
So you could unconditionally use `thread->vthread()`.

>> test/hotspot/jtreg/serviceability/jvmti/vthread/VirtualThreadStartTest/libVirtualThreadStartTest.cpp line 54:
>> 
>>> 52:     started_thread_cnt++;
>>> 53:   }
>>> 54:   deallocate(jvmti, jni, (void*)tname);
>> 
>> This will crash if `get_thread_name()` returns the string constant `"<Unnamed thread>"`
>
> Nice catch.
> It is strange I've never seen any related crashes.
> This could be addressed separately but I've fixed it now.
> Please, let me know if you are okay with it.
> Will submit more mach5 runs to be safe.

The fix looks good to me. Thanks for taking care of the issue right away.

-------------

PR: https://git.openjdk.org/jdk/pull/11246