On Thu, 26 Feb 2026 01:52:56 GMT, Alex Menkov <[email protected]> wrote:
>> 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()` > > Ok, I see now. Usage of `is_thread_carrying_vthread` is not obvious. > I suggest to explain it a bit, something like > // There are 2 cases when deoptimization is postponed: > // 1. Unmonted virtual thread - EnterInterpOnlyModeClosure will be executed > right after mount; > // 2. Carrier thread with mounted virtual thread - EnterInterpOnlyModeClosure > will be executed right after unmount. > > And update or remove the comment on return (it tells only about mount). Thank you for suggestion. What about this : // There are two cases when entering interp_only_mode is postponed: // - unmounted virtual thread - EnterInterpOnlyModeClosure::do_thread will be executed at mount; // - carrier thread with mounted virtual thread - EnterInterpOnlyModeClosure::do_thread will be executed at unmount. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29436#discussion_r2856592673
