On Tue, 27 Jan 2026 01:48:03 GMT, Serguei Spitsyn <[email protected]> wrote:
> The `interp-only` mechanism is based on the `JavaThread` objects. Carrier and
> virtual threads can temporary share the same `JavaThread`. The
> `java_thread->jvmti_thread_state()` is re-linked to a virtual thread at
> `mount` and to the carrier thread at `unmount`. The `JvmtiThreadState` has a
> back link to the `JavaThread` which is also set for virtual thread at a
> `mount` and carrier thread at an `unmount`. Just one of these two links at
> the same time is set to the `JavaThread`, the other one has to be set to
> `nullptr`. The `interp-only` mechanism needs this invariant.
> However, there is a corner case when this invariant is broken. It happens
> when the `JvmtiThreadState` for carrier thread has just been created. In such
> case, the link to `JavaThread` is always `non-nullptr` even though a virtual
> thread is currently mounted on a carrier thread. This simple update fixes the
> issue in the `JvmtiThreadState` ctor.
>
> Testing:
> - TBD: Mach5 tiers 1-6
src/hotspot/share/prims/jvmtiThreadState.cpp line 127:
> 125: thread->set_interp_only_mode(false);
> 126: }
> 127: if (JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) {
wouldn't be better to move this into the beginning of ctor:
if(!JvmtiEnvBase::is_thread_carrying_vthread(thread, thread_oop)) {
_thread = thread;
_thread_saved = nullptr;
} else {
_thread_saved = thread;
_thread = nullptr;
}
and might be add comments with explanation.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2733381607
