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