Hi Boris,
Am 03.08.2008 um 17:32 schrieb Boris Dušek:
On Sat, Aug 2, 2008 at 6:30 PM, Andreas Färber
<[EMAIL PROTECTED]> wrote:
I grabbed the Mono Preview 2.0 installer for OS X and wanted to test
new DTrace probes mentioned in Release Notes[1], but it did not
work.
Just to be sure, how did you test? As described in mono's man page?
With the same command that worked with mono that I compiled myself.
(with one difference - I used '/path/to/mono' for customly compiled
mono since my install prefix binary dir was not in $PATH):
[EMAIL PROTECTED]:~/Documents/dev/mono/usr/bin$ sudo dtrace -P
mono'$target' -l -c mono
ID PROVIDER MODULE FUNCTION
NAME
dtrace: failed to match mono3618:::: No probe matches description
[EMAIL PROTECTED]:~/Documents/dev/mono/usr/bin$ sudo dtrace -P
mono'$target' -l -c ./mono
ID PROVIDER MODULE FUNCTION
NAME
20188 mono3620 mono mono_gc_collect
gc-begin
20189 mono3620 mono mono_gc_collect
gc-end
21858 mono3620 mono mini_method_compile
method-compile-begin
21859 mono3620 mono mini_method_compile
method-compile-end
21860 mono3620 mono mini_init
ves-init-begin
21861 mono3620 mono mini_init
ves-init-end
Looks right.
btw. while we are at it, is it already possible now or do you plan to
add jstack support (so that the names of ".NET functions" appear
instead of addresses of frames for the part inside mono runtime?)
right now, with this Hello World program:
class Test {
public static void Main(string[] args) {
System.Console.WriteLine("Hello from C#");
}
}
and this tracing script (tracing usermode stack at every write
syscall):
syscall::write:entry
/pid == $target/
{
trace(arg0);
jstack();
}
I get this output which makes me believe it's either not implemented
or I am doing something wrong (both writes are to fd 1 = stderr):
[EMAIL PROTECTED]:~/Documents/dev/mono/usr/bin$
DYLD_LIBRARY_PATH=`pwd`/../lib sudo dtrace -s tracemono.d -c './mono
/Users/boris/Test.exe'
dtrace: script 'tracemono.d' matched 1 probe
Hello from C#
dtrace: pid 1528 has exited
CPU ID FUNCTION:NAME
1 17600 write:entry 1
libSystem.B.dylib`write$UNIX2003+0xa
mono`ves_icall_System_IO_MonoIO_Write+0x66
0x7d6084
0x7d5d60
0x7d5bae
0x7d5ae6
0x7cc8cd
0x7d4ed8
0x7d4e6e
0x7d4df8
0x7d4db6
0x7ca289
0x7ca24b
0x7ca1ce
mono`mono_runtime_exec_main+0xfe
mono`mono_runtime_run_main+0x153
mono`mono_main+0x1360
mono`start+0x36
0x2
1 17600 write:entry 1
libSystem.B.dylib`write$UNIX2003+0xa
mono`ves_icall_System_IO_MonoIO_Write+0x66
0x7d6084
0x7d5d60
0x7d5bae
0x7d5ae6
0x7cc8cd
0x7d63bf
0x7d61bd
0x7d614e
0x7d6128
0x7d4e0a
0x7d4db6
0x7ca289
0x7ca24b
0x7ca1ce
mono`mono_runtime_exec_main+0xfe
mono`mono_runtime_run_main+0x153
mono`mono_main+0x1360
mono`start+0x36
0x2
Tracing Java in this way yields empty trace, so probably it's me doing
something stupid.
DTrace support has been a recurrently requested feature for about two
years now. I'm happy that I got it working so far! :)
All current DTrace features are documented in mono's man page, that is
the six probes. I don't pretend that this is in any way conclusive,
there are many more probes and features imaginable, some listed as a
roadmap in the to-be Wiki documentation, see attached. Suggestions and
contributions always welcome. The current probes are meant to allow a
little profiling of the runtime, and were a convenient way for me to
trace what the runtime would be doing if my ppc64 port were working...
I haven't used jstack() yet and would need to look it up in the
documentation. It sounds non-trivial to implement compared to probes.
What I will be looking into next is method-enter/method-exit probes
for tracing managed function flow, but it seems more complicated (the
JIT would need to always emit a call to a helper function, supplying
it the data to conditionally pass out - otherwise the dynamic part of
DTrace wouldn't work) and thus cannot be on by default for performance
reasons, just like in Java.
Andreas
==Using DTrace with Mono==
Mono 2.0 includes DTrace probes when configured with
<code>--enable-dtrace</code>. This currently works on Solaris 10, OpenSolaris
and Mac OS X v10.5.
The idea behind DTrace is that production copies of software are traceable in
case problems arise, without needing to compile a debug version first. Both the
kernel and many daemons or applications allow tracing in a scripted,
event-oriented way.
You can use DTrace from the dtrace command line tool, graphically from
OpenSolaris' Chime or Apple's Instruments and from various scripting languages.
To check if DTrace is enabled in your copy of Mono, run the following command:
dtrace -P mono'$target' -l -c mono
This will list all probes of the "mono" provider in the executable "mono" or
display an error when no probes were found.
Note that using the dtrace command may require additional priviledges.
On Mac OS X use <code>sudo</code>.
On OpenSolaris use <code>pfexec</code> or adjust the user's priviledges
(/etc/user_attr)
to include <code>dtrace_user</code> and <code>dtrace_proc</code>, e.g., (as
root) <code>usermod -K defaultpriv=basic,dtrace_user,dtrace_proc
youruser</code>.
==The mono provider==
===ves-init-begin, ves-init-end===
Begin and end of runtime initialization.
With this pair of probes you can either profile the runtime initialization or
use them to constrain your analysis to initialization or post-initialization.
This example script outputs the time elapsed during runtime initialization:
mono$target:::ves-init-begin
{
self->start = timestamp;
}
mono$target:::ves-init-end
{
printf("%d\n", timestamp - self->start);
self->start = 0;
}
Run it as <code>dtrace -s thescript.d -q -c "mono YourApp.exe"</code>.
This should print the number of nanoseconds elapsed between the two probes.
===method-compile-begin, method-compile-end===
Begin and end of method compilation.
The probe arguments are class name, method name and signature,
and in case of method-compile-end success or failure of compilation.
The following D script, when run as <code>dtrace -s thescript.d -c "mono
YourApp.exe"</code>, prints all methods JIT'ed:
#pragma D option quiet
mono$target:::method-compile-begin
{
printf("%s::%s(%s)\n", copyinstr(arg0), copyinstr(arg1), copyinstr(arg2));
}
===gc-begin, gc-end===
Begin and end of Garbage Collection.
These probes are currently only enabled for the default Boehm GC (included or
system) but not yet for the in-progress Compacting GC.
==Roadmap==
Some work that might be done in the future includes:
* Add more probes
** method call tracing (should be disabled by default, cf. Java)
* Allow creating custom DTrace providers from managed code
* Create bindings for libdtrace
* Support more hosts
** FreeBSD
** QNX
_______________________________________________
Mono-list maillist - [email protected]
http://lists.ximian.com/mailman/listinfo/mono-list
