Starting with jdwp agent should not incur performance penalty

[Deneau, Tom]

I have filed an issue dealing with performance when a jdwp agent is
attached.  This issue has not yet become publicly visible but I was
hoping to start some discussion on it.  The internal review ID is
1630014 but if you can't see that, you can view the issue at the end
of this post.

Problem
-------
We can see how the code generation for throws gets affected by the value
Returned by jvmti_can_post_exceptions() which depends not on the
SetEventNotification state but on the capabilities state and is the OR
of the three capabilities,
*	Can_generate_exception_events
*	Can_generate_frame_pop_events
*	Can_generate_method_exit_events
and how these capabilities can only be set at agent_onload phase.
 
 
For example in share/vm/opto/parse2.cpp,
 
  case ByteCodes::_athrow:
 
    if (env()->jvmti_can_post_exceptions()) {  
      // "Full-speed throwing" is not necessary here,
      // since we're notifying the VM on every throw.
      uncommon_trap(Deoptimization::Reason_unhandled,
                    Deoptimization::Action_none);
      return;
    }
 
   .... //otherwise fastpath
 
   add_exception_state(make_exception_state(peek())));
   break;
 
 
And then deep in the uncommon_trap routine, in addition to all the
other exception handling, in JvmtiExport::post_exception_throw, the
jvmti_thread_state is checked to see if we really need to do a JVMTI
Exception event notification (if the debugger has not yet connected,
the answer is no).
 
 

General ways to attack this
===========================
 
General Solution 1)

  In the _athrow example above.....

   * if can_post_exceptions is true, generate code for a runtime check
     of the jvmti_thread_state, and to take the "slow path" only if
     jvmti_thread_state indicated that event notifications needed to
     be sent, otherwise branch to the "fast path" code.

  (this might have to be done in graphKit.cpp as well)

General Solution 2) 

* At compilation time do not compile in the "slow path" (which checks
  for jvmti notification) at all unless jvmti exception event
  notification is enabled in some jvmti_thread_state.  Thus in the
  normal situation where the jdwp agent is attached but debugger not
  attached, we would only compile the "fast path".

* At debugger attach time (ie, jvmti exception event notification
  enabled), all such compiled methods which could throw exceptions
  would need to get invalidated and possibly recompiled to include the slow path.


I'd be interested in the pros and cons of these two general solutions.
To me, solution 1 seems less intrusive.  Also, since the exception
event notification can have different values for different threads,
this allows some threads to take the fast path while others take the
slow path.
 

=======================================================================
Issue Description
=======================================================================

Title: Starting with jdwp agent should not incur performance penalty
---------------------------------------------------------------------
Description:
 A DESCRIPTION OF THE REQUEST :

If you start Java with the jdwp agent, for example using

   -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n

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.



JUSTIFICATION :
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.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The expectation is that starting with the jdwp agent does not incur a
noticeable performance penalty until the debugger attaches.

ACTUAL -
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.  workaround: