Java Performance when Debugging is Enabled


Earlier this year AMD, working with the Hotspot JVM team,  submitted a change to the OpenJDK to help the performance of Java applications which run with debugging enabled, in particular ones that also throw and catch exceptions as part of their flow control.  We’ve published the following article on the AMD Developer Central site which describes the situation in more detail, including a description of the Java Platform Debugging Architecture.

Read the article, “Java Performance When Debugging is Enabled.”

The changes described in the article are scheduled to appear in  JDK 6, Update 21.  Early access to Update 21 is available at They are also available in the latest OpenJDK 7 builds, see

We’d be interested in hearing of actual cases where people were affected by this performance issue.

Tom Deneau is a member of the Java Labs team at AMD. His postings are his own opinions and may not represent AMD’s positions, strategies or opinions. Links to third party sites are provided for convenience and unless explicitly stated, AMD is not responsible for the contents of such linked sites and no endorsement is implied.

5 Responses

  1. Mark Bickel

    In our webapplications we are using JSF 1.2 with Facelets. This setup seems to be affacted by the issue too, as the rendering of the Facelet application is nearly ten times slower when debugging is enabled (an no debugger connected). A JSP-based JSF 1.2 application running in the same server does not show such a extreme performance degradation. Unfortunately I was not able to test the early access Update 21 yet.

  2. tdeneau

    Mark —

    It would be interesting to see whether this Facelets setup slowdown with debugging enabled is indeed due to more exceptions being thrown. If it does speed up with Update 21, that’s almost certainly the cause. Meanwhile, another experiment to count the exceptions being thrown would be to add -agentlib:hprof=cpu=times to the java command line and look at how many times java.lang.Throwable’s constructor gets invoked. The constructor shows up as java.lang.Throwable.<init> I’m assuming you’ll see more of these in your Facelets setup compared to the JSP setup.

  3. Alessandro

    Very interesting, guys !

    I’d like you to suggest a article about Java EE & SE performance scalability across new multicore AMD processors, like X3, X4 and X6.

    That would be awesome 😉

  4. Mark Bickel

    Today I was able to test our Faclet application using the Update 21. The result is, that the update did not provide a measurable speed up when debugging is enabled (but debugger not connected). It is still very slow compared to the execution in an environment without debugging enabled.