dtrace discuss - Feb 2010 - Using dtrace to monitor native calls into Java code

Hello everybody.

I am trying to use dtrace to monitor native calls (from the Hotspot
VM) into Java code. Such calls occur, for instance, when invoking a
method using reflection.

I found this web page about dtrace probes in hotspot:
http://java.sun.com/javase/6/docs/technotes/guides/vm/dtrace.html

I tried out the probes. Especially, the Call*Method*-entry probes of
hotspot_jni looked promising. However, they do not seem to be
triggering, e.g. for reflective calls. Could the problem be that these
probes only monitor calls through JNI but Hotspot does not actually
use JNI to dispatch these calls into Java code? If so, does anybody
else have an idea of how to monitor reflective calls into Java code?

Best wishes,
Eric

--
Eric Bodden
Software Technology Group, Technische Universit?t Darmstadt, Germany
Tel: +49 6151 16-5478    Fax: +49 6151 16-5410
Mailing Address: S2|02 A209, Hochschulstra?e 10, 64289 Darmstadt

Eric Bodden wrote:
> Hello everybody.
> 
> I am trying to use dtrace to monitor native calls (from the Hotspot
> VM) into Java code. Such calls occur, for instance, when invoking a
> method using reflection.
> 
> I found this web page about dtrace probes in hotspot:
> http://java.sun.com/javase/6/docs/technotes/guides/vm/dtrace.html
> 
> I tried out the probes. Especially, the Call*Method*-entry probes of
> hotspot_jni looked promising. However, they do not seem to be
> triggering, e.g. for reflective calls. Could the problem be that these
> probes only monitor calls through JNI but Hotspot does not actually
> use JNI to dispatch these calls into Java code? If so, does anybody
> else have an idea of how to monitor reflective calls into Java code?
Right.  Hotspot does not use JNI to dispatch to native code.  The 
method-entry/return calls might help out here, but they monitor all 
calls which may be overkill for what you''re doing.

--
- Keith

> Right. ?Hotspot does not use JNI to dispatch to native code.
Thanks Keith, for confirming this. That''s too bad.
> The
> method-entry/return calls might help out here, but they monitor all calls
> which may be overkill for what you''re doing.
Indeed, I am specifically interested in identifying code that is
called through reflection. You are right, method-entry/return does
trigger for reflective calls but, as you say, it also triggers for
other calls.

Do you know if there''s a way to get (part of) the call stack for a
method-entry probe?

Eric

Eric Bodden wrote:
>> Right.  Hotspot does not use JNI to dispatch to native code.
> 
> Thanks Keith, for confirming this. That''s too bad.
> 
>> The
>> method-entry/return calls might help out here, but they monitor all
calls
>> which may be overkill for what you''re doing.
> 
> Indeed, I am specifically interested in identifying code that is
> called through reflection. You are right, method-entry/return does
> trigger for reflective calls but, as you say, it also triggers for
> other calls.
I don''t know a way of tracing only reflection calls.  The probe points 
in hotspot are currently rather course-grained, though it is not hard to 
add more if the appropriate locations are found.

However in this case I doubt that there''s an appropriate code path in 
the JVM that can be instrumented to give you this information reliably. 
  Hotspot tries to arrange things so that executing Java code will 
directly call the target method without dropping into the VM, even for 
reflective calls.

If you''re up for an adventure, one attempt may be to download the jdk7 
sources and instrument the java.lang.reflect code with the Java 
user-level tracing calls in com.sun.tracing.
> Do you know if there''s a way to get (part of) the call stack for a
> method-entry probe?
Of course, as with any probes, the ustack() (or jstack()) actions should 
give you a full stack trace.  (although there is an issue getting Java 
frames on some architectures if you''re using the server compiler).


--
- Keith

Hi again.
> However in this case I doubt that there''s an appropriate code path
in the
> JVM that can be instrumented to give you this information reliably.
?Hotspot
> tries to arrange things so that executing Java code will directly call the
> target method without dropping into the VM, even for reflective calls.
Do you mean these GeneratedMethodAccessors etc.? I know that the JDK
generates those sometimes, but not always, depending on how frequently
the method is invoked (usually more than 15 times). If the method is
called rather infrequently, then reflection appears to go through a
native interface. Ideally, I would like to trace both.
> If you''re up for an adventure, one attempt may be to download the
jdk7
> sources and instrument the java.lang.reflect code with the Java user-level
> tracing calls in com.sun.tracing.
Hmm, I was trying to avoid that but it may be an option of last resort...
> Of course, as with any probes, the ustack() (or jstack()) actions should
> give you a full stack trace. ?(although there is an issue getting Java
> frames on some architectures if you''re using the server compiler).
Oh, I did not know that feature. That may end up being useful. Thanks again!

Eric