On Mon, 21 Nov 2022 19:08:16 GMT, Serguei Spitsyn <sspit...@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
