On 06/25/2014 01:04 PM, Fitzgerald, Nick wrote:
Yes! We'd absolutely love to show code coverage in the debugger's
source editor! We've played with implementations based on
Debugger.prototype.onEnterFrame and hidden breakpoints, but it is
pretty slow and feels like a huge hack. Would this work likely yield
improved performance over that approach?
If this pans out, I'd expect it to be faster, but how much depends on a
lot of variables. I wish I could be more specific.
Note that the API would not directly offer all these features.
Instead, it
would offer some powerful but mind-boggling way of instrumenting all JS
code. It would be up to you, the user, to configure the
instrumentation, get
useful data out of it, and display or analyze it. There would be some
overhead
when you turn this on; we don't know how much yet.
Would the API be something like DTrace? Just want to figure out what
kind of thing we are talking about here.
Very good question. I too am interested in figuring out what kind of
thing we're talking about.
One proposal is to build something like strace: it would be impossible
to modify the instrumented code or its execution, only observe.
User-specified data about JS execution would be logged, then delivered
asynchronously. (Don't read too much into this -- the implementation
would be completely unlike strace. Note too that records would *not* be
delivered synchronously and would not contain stacks, though you could
recover the stack from enter/leave records.)
An alternative involves letting you modify JS code just before it's
compiled (source-to-source transformation). This is more general (you
could modify the instrumented code arbitrarily, and react synchronously
as it executes) but maybe that's undesirable. It's not clear that
transformed source would interact nicely with other tools, like the
debugger. And a usable API for this is a tall order.
So. Tradeoffs.
/me raises hand
Mostly interested in tracing calls and mutations. Also code coverage,
but to a bit of a lesser extent.
Great, we'll get in touch off-list!
Record/replay is such a holy grail (eclipsed only by "time traveling"
/ reverse and replay interactive (as opposed to a static recording)
debugging with live, on-stack code editing) that I hesitate to even
get my hopes up...
Don't get your hopes up.
A dynamic analysis API would help with the "record" side of rr-style
record/replay **of JS code alone**. You'd draw a boundary around all JS
code and capture all input across that boundary. But replay requires
more work in the engine. A bigger problem is that in such a scheme,
replay only reproduces what happens inside the boundary, and the DOM, in
this scenario, is still on the outside. A real record/replay product
would have to support the DOM too. We're far from being able to do that.
The dynamic analysis API would only be one part of the puzzle. I'm sorry
for the misleading gloss.
-j
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
