On Wed, 8 Apr 2026 05:04:03 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 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: (1) remove unneeded assert, (2) simplify one statement in > JvmtiEnvBase::set_frame_pop **NOTE on the new `com/sun/jdi` stress test:** `test/jdk/com/sun/jdi/StepOverStressTest.java` This test shows that this fix give us a performance gain which comes from the execution of JDI step over commands in compiled mode, so that all frames of the target thread are compiled except the frame with a registered `FramePop` event which is kept in `interp-only` mode. Without this fix the whole thread is executed in `interp-only` mode until we are done with single stepping or any other debugger activity which enforces `interp-only` mode. Below is shown the execution time difference: ======================================================== **NO OPTIMIZATION:** real 2m19.274s user 3m19.608s sys 0m7.905s Got BreakpointEvent #1: BreakpointEvent@TestTarg:54 in thread main Got StepEvent: StepEvent@TestTarg:55 in thread main **Total time #1: 93129** Got StepEvent: StepEvent@TestTarg:56 in thread main Got BreakpointEvent #2: BreakpointEvent@TestTarg:56 in thread main **Total time #2: 93395** **========================================================** **WITH OPTIMIZATION:** real 0m48.807s user 1m54.298s sys 0m7.400s Got BreakpointEvent #1: BreakpointEvent@TestTarg:54 in thread main Got StepEvent: StepEvent@TestTarg:55 in thread main **Total time #1: 546** Got StepEvent: StepEvent@TestTarg:56 in thread main Got BreakpointEvent #2: BreakpointEvent@TestTarg:56 in thread main **Total time #2: 789** ------------- PR Comment: https://git.openjdk.org/jdk/pull/28407#issuecomment-4294095334
