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

Serguei Spitsyn sspitsyn at openjdk.org
Thu Feb 26 02:46:43 UTC 2026


On Thu, 26 Feb 2026 01:52:56 GMT, Alex Menkov <amenkov at openjdk.org> 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


More information about the serviceability-dev mailing list