[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