On Thu, 21 May 2026 00:20:56 GMT, Serguei Spitsyn <[email protected]> wrote:
>>> it might impact the JDWP agent and a couple of JVMTI agents that use >>> debugging features like FramePop events; the Java agents are not impacted >>> (as Alan mentioned) >> >> This is not correct because of a bug in the implementation of JVMTI >> Capabilities. >> Now, this can potentially impact any agents including Java agents. > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28407#discussion_r3282822266
