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
_______________________________________________
dtrace-discuss mailing list
[email protected]
