On Wed, 25 Feb 2026 21:29:44 GMT, Alex Menkov <[email protected]> wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: convert a couple of sanity checks into asserts
>
> src/hotspot/share/prims/jvmtiEventController.cpp line 381:
>
>> 379: if (target == nullptr ||
>> // an unmounted virtual thread
>> 380: JvmtiEnvBase::is_thread_carrying_vthread(target,
>> state->get_thread_oop())) { // a vthread carrying thread
>> 381: return; // EnterInterpOnlyModeClosure will be executed right after
>> mount.
>
> The condition is not clear to me. How we do the deoptimization for mounted
> vthread?
Thank you for checking. It can be done in two different ways. The
`JvmtiThreadState` of a mounted virtual thread will be used to enter
`interp_only_mode` for mounted virtual thread. The `state->get_thread()` has to
be non `null` in both cases.
One way is when virtual thread is currently mounted. The chain of calls is:
`SetEventNotificationMode()` =>
`JvmtiEventControllerPrivate::set_user_enabled()` =>
`JvmtiEventControllerPrivate::recompute_enabled()` =>
`JvmtiEventControllerPrivate::recompute_thread_enabled() =>
`JvmtiEventControllerPrivate::enter_interp_only_mode()` => . . .
`EnterInterpOnlyModeClosure::do_thread()`
Another way is at a `mount` transition point. The chain of calls is:
`JavaThread::rebind_to_jvmti_thread_state_of()` =>
`JvmtiThreadState::process_pending_interp_only()` =>
`JvmtiEventController::enter_interp_only_mode()` =>
`EnterInterpOnlyModeClosure::do_thread()`
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2856056603
