On 6/15/2010 9:29 PM, Scott Feldstein wrote:
Ryan,
Thanks for the reply.
How do I apply the sampling technique that you mentioned to the method-entry
and method-return blocks of code? That is my big problem. The ustack() just
returns the stack as the OS sees it, not the jvm. Maybe I just need to dig
through the java probes a bit more to see if i can find something with the same
functionality.
thanks.
Hi Scott,
Profiling and entry/return probes are orthogonal approaches. You can use
both simultaneously, though that's rarely useful. Entry/return
intercepts *every* call and return, jumping to the kernel to do dtrace-y
things. Very expensive (adds ~50usec/call), especially if there are lots
of small functions. That's what the script you submitted was doing.
I'm suggesting to use profiling, where the kernel raises interrupts on
every core in the system at the specified frequency (e.g. 101hz), and
the interrupt's handler runs the dtrace probe (in my case stuffing the
stack trace in an aggregation). Much cheaper (~50usec every 1-10msec),
but you only get a sampling back instead of exact traces -- whatever
happened to be running on that core when the interrupt fired.
Also, as I mentioned before, you probably want 'jstack' instead of
'ustack' (see
http://wikis.sun.com/display/DTrace/Actions+and+Subroutines for
explanations of stack/ustack/jstack). I'd start simple, with a profile
probe aggregating over jstack, and go from there.
Hope that makes sense,
Ryan
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
