JDK-6902182 : Starting with jdwp agent should not incur performance penalty
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6u10,6u18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_10
  • CPU: generic,x86
  • Submitted: 2009-11-17
  • Updated: 2017-01-11
  • Resolved: 2010-02-09
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 6 JDK 7 Other
6u21Fixed 7Fixed hs17Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
If you start Java with the jdwp agent, for example using


you will see that the jdwp agent enables the
   * can_generate_exception_events
capability but does not enable exception event notification until a
debugger actually attaches to the socket.  (This can be confirmed
using the -XX:TraceJVMTI option).

Yet just using the jdwp agent and not attaching the debugger still
results in a large decrease in performance for applications which
throw exceptions, at least for the server compiler.

Note that it is not a workaround to just delay the attachment of the
jdwp agent using the com.sun.tools.attach API.  The jdwp agent does
not have the Agent_OnAttach entry point, and even if it did, the
capabilities that the jdwp agent adds can only be added at JVM
initialization time.

This is important because many applications start the JVM with the
jdwp agent in case they might want to attach the debugger at some
later time.  This happens even in production environments and the
expectation is that starting with the jdwp agent does not incur a
noticeable performance penalty until the debugger attaches.

The expectation is that starting with the jdwp agent does not incur a
noticeable performance penalty until the debugger attaches.

The actual behavior is that starting with the jdwp agent does incur a
noticeable performance penalty for apps that throw exceptions even though the debugger has not attached.

EVALUATION This evaluation entry is from Tom Deneau @ AMD: This webrev adds some logic to the jvmtiThreadState to cache a new boolean flag, should_post_on_exceptions, which is true if reporting is currently enabled on that thread for any of the following events (throws, catches, method exit, frame pop). Then, in the code generation for throws, if the capabilities for any of these events are on, a runtime check of the new should_post_on_exceptions flag is generated. Previously, we only checked whether the capabilities for these events were enabled thru jvmtiExport::can_post_on_exceptions(). The new logic allows us to avoid an uncommon trap and deoptimization for cases where the capabilities is enabled but the event reporting is not enabled, which is the case when for example we have started with the jdwp agent but not yet connected the debugger. In addition, when the deoptimization does have to be performed, it is done without using a global safepoint which makes it less costly. All changes are platform-independent. Numbers from a JIRA-based web workload. (JIRA makes fairly heavy use of exception throws and catches). Here we compare the scores without the jdwp agent to the scores with the agent installed but the debugger not yet connected. Scores are relative to the no-jdwp-agent case. JIRA JIRA 40 Users 1 User no jdwp agent 100% 100% old hotspot, with jdwp agent 15% 30% new hotspot, with jdwp agent 97% 87%

EVALUATION ChangeSet=http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6deeaebad47a,ChangeRequest=6902182