<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 21, 2015 at 10:52 AM, Lukas Larsson <span dir="ltr"><<a href="mailto:lukas@erlang.org" target="_blank">lukas@erlang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>* Allow multiple tracers. Today only one port/process can be the receiver of trace data.</div></blockquote><div><br></div><div>This would be especially welcome. You can run profiling next to debug-tracing then, which is a nice thing.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>  * Better integration of dtrace/lttngt/systemtap into the erlang trace.<br></div></blockquote><div><br></div><div>My advice would be: Study the DTrace model. Steal every good idea. In DTrace, you enable probes, then define a filter set on those probes and then you define what action (i.e., program) to run if the filter is passed.<br><br></div><div>Example: People have requested a "who calls me" query. Suppose we had a probe in DTrace for when a function calls another function, in module 'm'<br><br></div><div>erlang*:::funcall<br></div><div>/ copyinstr(arg1) = "m" /<br></div><div>{<br></div><div>    caller = current_function()<br>}<br><br></div><div>erlang*:::global-function-enry<br>{<br></div><div>    @callers[caller] = count()<br>}<br><br></div><div>This would in principle be enough to satisfy that query, if only we extended DTrace probes a little bit. It would output a list of pairs [{Caller, Count}].<br><br></div><div>Second observation: DTrace has something called a ustack(), which is the backtrace stack in Userland. We can get that for the C layer in BEAM, but we can't look into it for the Erlang world. The ustack() helpers are D-scripts (they run in the kernel, and can only have finite loops among other things). So we would probably need an easy way, in a struct, where we can grab information about the frames on the emulator stack from the kernel. Any tracing facility outside the Erlang world needs this.<br><br></div><div>Third observation: Simon's request is also easily satisfiable. Set a tick timer at 997Hz from the kernel, then look up where we are once the timer ticks. Preferably once per scheduler thread.<br></div><div> <br>Key takeaway: Provide tools, not solutions. Once you can enable probes 
and filter probes, a process can tie actions to probes like the above. We can always push specialized optimizations down into the tracing layer for efficiency, but we should go for a variant where we provide enabling tools for programmers, rather than baked solutions.<br><br></div><div>I envision that things such as e2_debug, recon_trace, redbug and so on are adaptable to a new model, easily.<br><br></div><div>Finally, we should really write a good dbg tutorial together with better documentation. I'm willing to throw some hours into this if needed :)<br></div></div><br><br clear="all"><br>-- <br><div class="gmail_signature">J.</div>
</div></div>