On Thu, 21 May 2026 16:39:34 GMT, Patricio Chilano Mateo <[email protected]> wrote:
>> I've implemented and pushed the following suggestion from >> [pchilano](https://github.com/pchilano): >> >>> I see JvmtiExport::can_post_interpreter_events() will be set for agents >>> loaded at start-up. So even if we don’t enable notifications for method >>> exit or frame pop events we will still make this VM call on method exit. >>> Maybe we could keep the interpreter only mode check for method exit cases, >>> and also add a new check for frame pop events? We could have something >>> similar to check_and_handle_earlyret, where we check for the >>> JvmtiThreadState first and then another field which will be set when there >>> is at least one frame pop request. Given that there could be multiple >>> environments, a simple solution could be to set a boolean in the >>> JvmtiThreadState when we set a frame pop notification request, and then >>> clearing it in post_method_exit if there are no requests left. >> >> With this update I do not see any overhead with -Xint and a JVMTI agent >> enabling interp-only capabilities. >> >> I've not implemented this suggestion for `ppc_64`, `riscv` and `s390` though >> as I'm not sure, we can safely test those architectures. If we do then I'll >> prepare one more update for `ppc_64`, `riscv` and `s390`. > > Great. FTR the extra overhead I noticed was only when requesting capabilities > that included one of the `interp_events` events. I thought I had also seen it > even with other non-interpreter events but that is not the case. I also > double checked now and see that even with `interp_events` capabilities > enabled there are no extra calls to the VM. > > I’m thinking if the case where we enable method_exit event globally works > correct for virtual threads that are unmounted. Isn’t it the case that > unmounted vthreads might not have a `JvmtiThreadState` yet? In that case, > once the vthread is mounted again we won’t post this event until the > `JvmtiThreadState` is created. I know we have lazy creation of the state, but > where would that happen in that case? I see we have a call to create the > state in `JVMTIEndTransition` but only for the `_is_thread_start` case. This > question also applies to the previous code where we were only checking for > `_interp_only_mode`, since that would be set in > `JvmtiThreadState::process_pending_interp_only` during mount, but only if > there is already a `JvmtiThreadState`. No need to fix it here if this is a > preexisting issue, but was wondering about this case. Thank you for the concern. But as I see the `JvmtiThreadState` for unmounted virtual threads will be lazily created in the `post_method_exit()`: void JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) { . . . JRT_BLOCK bool interp_only = thread->is_interp_only_mode(); // Avoid calls to get_jvmti_thread_state if is_interp_only_mode was not enabled. state = interp_only ? get_jvmti_thread_state(thread) : thread->jvmti_thread_state(); <== !!! The `get_jvmti_thread_state()` is called if `interp_only` is set. The `interp_only` has to be set if `MethodExit` events are enabled globally. Please, let me know if I miss anything here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28407#discussion_r3286624852
