<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 21, 2015 at 3:41 PM, Vlad Dumitrescu <span dir="ltr"><<a href="mailto:vladdu55@gmail.com" target="_blank">vladdu55@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi!<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Sep 21, 2015 at 12:02 PM, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf@feuerlabs.com" target="_blank">ulf@feuerlabs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span><div><blockquote type="cite"><div>On 21 Sep 2015, at 10:52, Lukas Larsson <<a href="mailto:lukas@erlang.org" target="_blank">lukas@erlang.org</a>> wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">To start the discussion, here are a few of my ideas in no particular order:</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">  * Allow multiple tracers. Today only one port/process can be the receiver of trace data.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">  * Create a couple of scalable high throughput tracing output backends with different overflow mechanics. Today all tracing is funneled through one bottleneck and has no overflow handling at all.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">  * Expose vm probes (today dtrace probes) to the erlang tracer.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">  * Better integration of dtrace/lttngt/systemtap into the erlang trace.<br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">  * Allow the erlang tracer to be an Erlang callback module. Today only ports/processes are allowed.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">  * Optimize trace output to file/ip. Maybe use something like the Common Trace Format (<a href="http://git.efficios.com/?p=ctf.git;a=blob_plain;f=common-trace-format-specification.md;hb=master" target="_blank">http://git.efficios.com/?p=ctf.git;a=blob_plain;f=common-trace-format-specification.md;hb=master</a>), instead of the term_to_binary that we have today.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">  * Write much much better documentation for dbg :)</div></div></blockquote><br></div></span><div>+1 on the suggestions, esp. multiple tracers. The one-tracer restriction makes it hard to explore some very interesting monitoring and debugging ideas.</div></div></blockquote><div><br></div></span><div>Those are very good starting points. </div><div><br></div><div>For multiple tracers, I would assume that they will be independent - i.e. not all of them get all tracing events, but only the ones they are interested in. The question is if the tracing engine can be made fast enough, possibly only if the filtering criteria are restricted to term matching (as opposed to arbitrary predicates provided by users). </div></div></div></div></blockquote><div><br></div><div>Yes, they would be independent. I envision filtering being done as today, i.e. through match specs that are run for when a trace pattern that has been triggered. Each tracer would have it's own filter that has to be executed before a decision is made whether a trace should be generated or not, so having multiple tracers will be more expensive than one. Luckily it is quite hard to write long match specs, so normally each filter is very fast to be checked :)</div><div><br></div></div></div></div>