[Mono-list] [Mono-dev] Mono preview 2.0 binary and DTrace

[Andreas Färber]

Ciao Massi,

Am 05.08.2008 um 08:23 schrieb Massimiliano Mantione:

>
> On Sun, 2008-08-03 at 21:57 +0200, Andreas Färber wrote:
>> 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.
>
> IMO, the correct way of doing this would be to implement it in a
> profiler module, and it's amazingly easy doing so.

Although not really familiar with it, I am aware of the existing cross- 
platform tracing and profiling mechanisms in Mono. (The JIT profiling  
DTrace probes mostly match Mono's own hooks except that I reported  
some profiler hooks were missing for generic sharing and when some  
optimizations were not run - I got no reply to that, maybe you want to  
check on that.)

DTrace is a different paradigm...

> But actually the logging profiler does just that if you invoke it with
> the "c" option: it logs all method enter and exit events.
> It uses per-thread buffers (periodically flushed) to minimize overhead
> and locking, each event takes between 2 and 5 bytes in the log file
> (including the full timestamp!), and even this way the overhead is
> really high.
> I doubt dtrace could be any faster... but if it is I'd like to know  
> how
> it does it :-)

...currently, having to start mono with the DTrace tool as documented  
is an intermediate step - the final goal is to deploy a runtime with  
DTrace compiled in, no probes activated at startup. Then when  
something goes wrong, e.g. while running ASP.NET with mod_mono, you  
connect to the mono pid (or to all running mono instances) and see  
what's going on.

What DTrace is doing afaik is it pre-compiles the D script to bytecode  
and it has per-CPU buffers. Unless I activate a certain probe, no data  
gets collected for it. Even if activated (i.e., called and data passed  
into), the script can use predicates to minimize the data collected to  
that of interest (e.g., only profile compilation of method starting  
with A), and built-in aggregation functions can further reduce the  
amount of data actually kept (e.g., a histogram). So this means that  
the actual "if (enabled)" needs to be different, and I wouldn't want  
to mess with the semantics of the cross-platform mechanism.

Personally, I have used DTrace for my thesis on H.264 SVC streaming,  
and being under great time pressure DTrace has allowed me to get the  
statistics I wanted with a minimum of work - for absolute numbers I  
got histograms directly in GNUplot format, for a cumulative  
distribution function I postprocessed the output with an existing Mono  
tool of mine (probably there's an easier way too but I'm no expert).
http://www.informatik.uni-mannheim.de/pi4/publications/Faerber2008a  
(pp. 14ff)

Anyway, believing that DTrace will be slightly faster, I have taken  
care to place the DTrace probes enclosed by Mono's hooks (e.g., start  
profiler hook, start DTrace probe, whatever, end DTrace probe, end  
profiler hook) and would ask that we stick with this order. It should  
not have any influence when DTrace is not compiled in (e.g., Linux) as  
my macros become no-op then.

I don't wish to replace or belittle your profiler work. I think the  
two have different scopes and different use cases and can live side by  
side, even benefitting from increased review.

Andreas