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>);
</xsl:text>
<xsl:text> if (method_oop == NULL) {
</xsl:text>
causes hprof to run noticeably faster.
|
Java