JDK-6862945 : conversion of jmethodID to methodOop in JVMTI is too expensive
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: hs16,6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_9
  • CPU: generic,sparc
  • Submitted: 2009-07-22
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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
6u18Fixed 7Fixed hs16Fixed
Related Reports
Relates :  
JDK-6404550 - Cannot implement late attach in NetBeans Profiler due to missing functionality in JVMTI
Relates :  
JDK-6949515 - VM crash when calling GetMethodDeclaringClass
Description
While hacking on hprof I became intrigued by why it's so ridiculously slow when dumping traces.  Digging around a bit showed that the problem was that converting a jmethodID to a methodOop always uses JNIHandles::checked_resolve_jmethod_id which attempts to confirm that the JNI reference being used is weak.  Unfortunately this requires searching the entire set of weak JNI handles to see if it's in the table and since hprof is using a huge number of weak references this becomes very slow.  It's also not a very interesting thing to test for since it never actually checks that the underlying object is really a methodOop which seems a lot more important.  Making the following change:

diff --git a/src/share/vm/prims/jvmtiEnter.xsl b/src/share/vm/prims/jvmtiEnter.xsl
--- a/src/share/vm/prims/jvmtiEnter.xsl
+++ b/src/share/vm/prims/jvmtiEnter.xsl
@@ -896,7 +896,7 @@ static jvmtiError JNICALL

 <xsl:template match="jmethodID" mode="dochecks">
   <xsl:param name="name"/>
-  <xsl:text>  methodOop method_oop = JNIHandles::checked_resolve_jmethod_id(</xsl:text>
+  <xsl:text>  methodOop method_oop = JNIHandles::resolve_jmethod_id(</xsl:text>
   <xsl:value-of select="$name"/>
   <xsl:text>);&#xA;</xsl:text>
   <xsl:text>  if (method_oop == NULL) {&#xA;</xsl:text>

causes hprof to run noticeably faster.
Comments
EVALUATION http://hg.openjdk.java.net/hsx/hsx16/master/rev/1760a1cbed36
04-09-2009
EVALUATION http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/1760a1cbed36
28-08-2009
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1760a1cbed36
11-08-2009
SUGGESTED FIX Please see attached 6862945-webrev-cr1.tgz for the proposed fix after changes to address round 0 comments.
11-08-2009
SUGGESTED FIX Please see attached 6862945-webrev-cr0.tgz for the proposed fix.
10-08-2009
EVALUATION JNIHandles::checked_resolve_jmethod_id() is used at the JVM/TI function layer to sanity check incoming jmethodID values and is also used by the JNI sanity check logic (-Xcheck:jni). checked_resolve_jmethod_id() calls JNIHandles::is_weak_global_handle() which gets more expensive as the number of weak global handles increases. I think the is_weak_global_handle() call is more appropriate for the -Xcheck:jni code path where more caution is explicitly requested. I plan to refactor checked_resolve_jmethod_id() and move the is_weak_global_handle() call to jniCheck::validate_jmethod_id(). checked_resolve_jmethod_id() will do NULL checks and an "is this a method?" check. Possibly other checks too.
06-08-2009