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.
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.
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.
--
Nicolas B. Pierron
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
