On Tue, Jul 1, 2014 at 8:29 PM, Nicolas B. Pierron < [email protected]> wrote:
> On 07/01/2014 11:11 AM, Till Schneidereit wrote: > >> On Tue, Jul 1, 2014 at 7:52 PM, Jason Orendorff <[email protected]> >> wrote: >> >> The proposed implementation technique underlying this is bytecode >>> instrumentation. One reason for this is that we already have tons of >>> practice >>> adding new opcodes to Ion, baseline, and the interpreter. We already know >>> how >>> to make them work the same in all modes and fast in Ion. Of course the >>> implementation technique could vary per event. If we choose to support an >>> event >>> that already has a natural choke-point in C++, we would not need bytecode >>> instrumentation to intercept that event. It is also true that bytecode >>> instrumentation has a few weaknesses--things like exception handling are >>> not >>> done by executing bytecodes at all. >>> >>> >> Isn't this exactly what tracelogging does? Or, a subset of what >> tracelogging does, rather? >> > > For this precise point, yes. > > Which is why I also discuss with Hannes about the Tracelogger. The main > difference is the exposure through Debugger. But keep in mind that this > first aspect would be the ground work for the incremental updates of this > API, and that we can instrument on-demand based on what is monitored by all > the Debuggers. > Sure, I was mostly talking about the bytecode instrumentation and efficient storage of recorded data. > > Code coverage might want to have a per-block overview of the code usage, > or per-instruction overview, depending on how much overhead is acceptable. > > I think the Tracelogger output is only one kind of information that we > want to expose through any analysis API, such as we can stream & process > events, and make it available inside the debugger. > Fully agreed, and I'm looking forward to seeing more kinds of events. > > One of the difference between the Tracelogger and what we want to achieve > at first here, is that we only want to observe one compartment, and not all > runtimes of the browser. (is there a tracelogger filter?) One of the thing > that I would hope to see exposed to web developers would be the time spent > in the Parser / GC of each compartment. > The tracelogger has filtering implemented, yes. I don't think it supports by-compartment filtering yet, but that should be easy to add. To be useful in a devtool, I think it should have filters that apply to what's on stack. I.e., start recording as soon as a matching function enters the stack, but then record everything. And probably use a cycle buffer that is allocated once and kept around. I guess for the Debugger usage that is pretty simple: send an update over the wire once the buffer is full and then start at the beginning. Oh, and it should probably record data with time- instead of tick-based timestamps. I think Hannes didn't do that because the logger's overhead invalidates the data. However, tracelogging has fairly small overhead nowadays, so I think this might be reconsidered. On Tue, Jul 1, 2014 at 8:46 PM, Jason Orendorff <[email protected]> wrote: > > On 07/01/2014 01:11 PM, Till Schneidereit wrote: > >> Isn't this exactly what tracelogging does? Or, a subset of what >> tracelogging does, rather? >> > > Similar. I had the impression trace-logging data was more like IONFLAGS > spew: mainly of interest to people working on the JITs. > > But if that data would be useful to devtools or anyone else, yes, it's a > prime candidate to be exposed through the new API. > Hannes and I have been talking about this quite a bit, and I at least would love for this info to be exposed. For Shumway, we've built our own profiler, and because it was really simple to do, we've implemented an importer for tracelogging data: http://codeazur.com.br/shumway/tracelogger/ (try zooming in with your mousewheel on, for example, pdfjs. And scroll down with shift held. The UI isn't yet ideal ...) Combined with proper filtering of events as described above, this would be very useful, I think. _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
