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 enabling the `interp-only` mode for threads when `FramePop` events are enabled with JVMTI `SetEventNotificationMode`. Instead, the target frame has been deoptimized and kept interpreted by disabling `OSR` in the function `InterpreterRuntime::frequency_counter_overflow_inner()`. 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. It is considered to file a SCR for this update a `FramePop` events do not enforce the `interp-only` mode for a target thread anymore which might break some expectations (the behavior has been changed). Testing: - test `serviceability/jvmti/vthread/ThreadStateTest` was updated to provide some extra test coverage - submitted mach5 tiers 1-6 ------------- Commit messages: - 6960970: Debugger very slow during stepping Changes: https://git.openjdk.org/jdk/pull/28407/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28407&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6960970 Stats: 282 lines in 21 files changed: 200 ins; 57 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/28407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28407/head:pull/28407 PR: https://git.openjdk.org/jdk/pull/28407
