RFR: 8296323: JVMTI can_support_virtual_threads not available for agents loaded into running VM [v4]
Serguei Spitsyn
sspitsyn at openjdk.org
Tue Nov 22 05:16:46 UTC 2022
On Mon, 21 Nov 2022 22:30:28 GMT, Richard Reingruber <rrich at openjdk.org> wrote:
>> 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()`.
Got it, thanks.
Removed the check for NULL and added the assert.
The simplification is minor but still worth it.
Please, let me know if you are okay with the update.
-------------
PR: https://git.openjdk.org/jdk/pull/11246
More information about the serviceability-dev
mailing list