On Thu, 7 May 2026 18:09:44 GMT, Serguei Spitsyn <[email protected]> wrote:
>> Thank you for this suggestion! Yes, this makes sense to do. However, it >> would be nice to separate it from this PR. I'll file a performance bug if >> you are okay with it. The performance impact should not be that big in >> general while it is still important. >> It is because: >> - 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) >> - only the `notify_method_exit` interpreter chunk is impacted, so it is >> already the interpreted slow path > >> 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`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28407#discussion_r3277901013
