RFR: 8373367: interp-only mechanism fails to work for carrier threads in a corner case [v9]

[Serguei Spitsyn]

On Wed, 25 Feb 2026 21:29:44 GMT, Alex Menkov <amenkov at openjdk.org> 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