[Mono-list] [Mono-dev] Mono preview 2.0 binary and DTrace
andreas.faerber at web.de
Tue Aug 5 06:26:40 EDT 2008
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
>> 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
> 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).
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.
More information about the Mono-list