Bug ID: JDK-6960970 Debugger very slow during stepping

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 25
25Unresolved

See http://netbeans.org/bugzilla/show_bug.cgi?id=187407

Steps to reproduce:
Get project from https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/JDK-7/j_l_Character_names/?rev=1094

$ svn co -r 1094 https://java-nio-charset-enhanced.dev.java.net/svn/java-nio-charset-enhanced/branches/JDK-7/j_l_Character_names --username guest

Build the project with configuration=parse_UnicodeSpec in NetBeans

$ cd JDK-7/j_l_Character_names
$ /opt/java/jdk1.7.0-b84/fastdebug/bin/java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=localhost:41614 -Dfile.encoding=UTF-8 -classpath build/classes build.tools.generatecharacter.UnicodeSpec make/tools/UnicodeData/UnicodeData.txt

In a second terminal:
$ jdb -attach 41614
stop at build.tools.generatecharacter.UnicodeSpec:337
resume
 (breakpoint is hit)
next
next
 (it takes a long time to complete)

When a breakpoint is submitted to line 340 and continue is used instead of step over, it completes much faster:

$ jdb -attach 41614
stop at build.tools.generatecharacter.UnicodeSpec:337
stop at build.tools.generatecharacter.UnicodeSpec:340
resume
 (breakpoint is hit)
resume
 (next breakpoint is hit in a short time)

With resume, the application executes much faster than with a step request active. The CPU is consumed by the debuggee and there's no communication with the debugger, therefore there seems to be something inefficient in the debugger backend.

This CR is really more of a JVMTI issue. I don't see how the debugger can work around it. JDK-8229012 however can possibly be resolved in the debugger, because I'm not convinced the NotifyFramePop being used in that case is even necessary. However, addressing this CR would also address JDK-8229012.
30-06-2021
It looks like I also filed JDK-8229012, which is very similar, although talks about a different NotifyFramePop. With JDK-8229012, the NotifyFramePop is done on the current frame you are stepping in. It's not clear why it is needed, but it keeps the thread in interp_only mode until the frame is exited. The NotifyFramePop above is a different one, but with similar results. It is done as part of "step over" handling. When you get the first SINGLE_STEP event in the method you are stepping over, single stepping is disabled, and the NotifyFramePop is setup so let you know when you exit the called method. Then single stepping is enabled again. So in this case you remain in interp_only mode the entire time the stepped over method is being called.
29-06-2021
Re-opening. This is still an issue and affect users. We should consider fixing it. The issue seems to be that the thread is forced to run interpreted during the "step over", and a lot of java execution is done during the step over. Although the debug agent disables single stepping events once we are in the method being stepped over (which normally would allow the thread to start compiling methods again), we also enable FramePop events. See the following code in stepControl.c: /* * We need to continue, but don't want the overhead of step * events from this method. So, we disable stepping and * enable a frame pop. If we're stepping into, we also * enable method enter events because a called frame may be * where we want to stop. */ disableStepping(thread); ... error = JVMTI_FUNC_PTR(gdata->jvmti,NotifyFramePop) (gdata->jvmti, thread, 0); The enabling of FramePop events we believe (but still need to confirm) is forcing the thread to remain in "interp only" mode. If this is the case, with some compiler support possibly this could be fix so the thread does not need to continue to run interpreted. The addition of return barrier support might make doing this more feasible.
13-03-2020
This is not on our list of current priorities. If this changes, please reopen this issue.
30-11-2016

Relates :	JDK-8340698 - JVMTI FRAME_POP event is sometimes missed if NotifyFramePop is called as a method is returning
Relates :	JDK-8229012 - When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes