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 _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list