On Fri, 22 May 2026 09:47:16 GMT, Serguei Spitsyn <[email protected]> wrote:
>> This change fixes a long standing performance issue related to the debugger >> single stepping that is using JVMTI `FramePop` events as a part of step over >> handling. The performance issue is that the target thread continues its >> execution in very slow `interp-only` mode in a context of frame marked for >> `FramePop` notification with the JVMTI `NotifyFramePop`. It includes other >> method calls recursively upon a return from the frame. >> >> This fix is to avoid enforcing the `interp-only` execution mode for threads >> when `FramePop` events are enabled with the JVMTI >> `SetEventNotificationMode()`. Instead, the target frame has been deoptimized >> and kept interpreted by disabling `OSR` optimization by the function >> `InterpreterRuntime::frequency_counter_overflow_inner()`. (Big thanks to >> @fisk for this suggestion!) Additionally, some tweaks are applied in several >> places where the `java_thread->is_interp_only_mode()` is checked. >> The other details will be provided in the first PR request comment. >> >> Testing: >> - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to >> provide some extra test coverage >> - submitted mach5 tiers 1-6 >> >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: 1. Add asserts, rem comment 2. Remove can_generate_frame_pop_events > from can_generate_interpreter_events > The problem is that InterpreterRuntime::post_method_exit is only called if > the JvmtiThreadState is not null already. Also, even previously where we only > checked _interp_only_mode in InterpreterMacroAssembler::notify_method_exit we > had this same issue. That field is set at mount point for the unmounted > vthread case, but only if there is a JvmtiThreadState already created ( > > [jdk/src/hotspot/share/prims/jvmtiThreadState.inline.hpp](https://github.com/openjdk/jdk/blob/3a9cb9a7c271d58a960e940cb4051217337d86a9/src/hotspot/share/prims/jvmtiThreadState.inline.hpp#L152) > > Line 152 in > [3a9cb9a](https://github.com/openjdk/jdk/commit/3a9cb9a7c271d58a960e940cb4051217337d86a9) thread->set_interp_only_mode(state != nullptr && state->_saved_interp_only_mode); ). I see we are missing a test case for this. A fix could be to check seen_interp_only_mode() at mount time and create the state if not present. We do that in ~JVMTIEndTransition() but only for the thread start case. Since this issue is preexisting we could address it in a separate bug though with an additional reproducer test. Good catch, thanks. I agree. Let's address it separately. I've filed new bug: [8385341](https://bugs.openjdk.org/browse/JDK-8385341) Create JvmtiThreadState lazily for unmounted vthread if MethodExit events enabled globally ------------- PR Comment: https://git.openjdk.org/jdk/pull/28407#issuecomment-4521230318
