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

[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.

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 :-)

What the profiler misses, in this case, is a GUI that is oriented
towards "browsing the log", maybe with a timeline, showing the threads
in parallel, and with a filter and fast search functions...

The data is all in the log, the problem is those log files can take
several hundreds of Mb on disk (with the events compacted that way), so
IMO keeping all the data in RAM in the GUI would be the wrong approach
(because each event would take much more than 5 bytes!).
This is the main reason why this kind of tool has not yet been written:
doing it well for the general case (a typical program run during more
than ten minutes) is not trivial.

But if you need only one line in a text file for each method enter-exit,
take the Mono.Profiler code, put a couple of WriteLine inside
MethodEnter and MethodExit in the EventProcessor, be sure to print also
"stack.Depth", and you have your trace :-)
As a bonus, if you want to be able to distinguish threads, also print
"stack.ThreadId".
It is worse than "mono --trace" because you don't have the method
arguments, but it is much more efficient during execution so there are
more cases when this is actually doable.

I *know* this is not dtrace, it does not profile the whole system but
only Mono... but this works also on Linux.

Ciao,
  Massi