[Mono-dev] [PATCH] Mono DTrace provider
Miguel de Icaza
miguel at novell.com
Tue May 27 15:39:19 EDT 2008
> i) A static probe has a performance impact even when the probe itself
> is not enabled. It's small, somewhere in the order of five nop
> instructions, I read for Solaris 10. On OSX the header file has one
> function call (and there is no postprocessing step to change this).
> Didn't do any benchmarks myself though.
> If we later add further static probes on "hot" paths such as JIT
> method compilation, I thought some people would not want to have that
> feature enabled if they know they'd not use it. But you're right, if
> anyone is so worried about performance they could of course explicitly
> use --disable-dtrace.
Where do those probes go?
But I agree that having folks use --disable-dtrace is better, if they
really care about that time.
>
> ii) I consider the build process changes for Solaris somewhat fragile
> and unportable, and therefore didn't want to enable them by default to
> not mess default builds of any upcoming release. We could resort to
> adding DTrace support only for Mac OS X for now if you dislike the
> changes and have no better idea. (I don't know about FreeBSD or QNX,
> it could be that they require similar postprocessing steps as Solaris
> since they all use ELF.)
>
> A third issue for automatically enabling it would be how to correctly
> detect DTrace availability. Some Linux distros were reported to ship a
> dtrace tool which is an ISDN tracer and totally unrelated to Sun's
> DTrace. Checking for the sys/sdt.h header might be a better heuristic,
> but I don't know.
>
> Andreas
>
More information about the Mono-devel-list
mailing list