1906719 - Implement a native backend for the JS tracer

Status: RESOLVED FIXED

(DevTools :: Debugger, enhancement)

Description

[Alex Thayer [:alexical] (she/her)]

This bug tracks the work to implement the backend of the JS execution tracer in native code for better performance. Initially this will just output to the profiler view.

Comment 1

[Alex Thayer [:alexical] (she/her)]

Attachment: Bug 1906719 - Implement a native backend for tracing JS execution r?arai

Basically the implementation we have with JS onEnterFrame callbacks and friends
is not sufficiently performant, and is a real pain to work with on large
complex websites. This implementation instead serializes all of the necessary
information to a ring buffer hanging off of the JSContext and outputs a JS
object containing that information when prompted.

There may be some subtle oddities in the design here, or more indirection in
some areas than you might expect. It should be kept in mind that this evolved
from a prototype which used a shmem to allow visualizing this trace live in the
parent process, which is a model we eventually want to return to, but this felt
like the safest first patch.

Comment 2

[Alex Thayer [:alexical] (she/her)]

Attachment: Bug 1906719 - Output native JS trace to the profiler r?ochameau

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'DevTools::Debugger' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[Alexandre Poirot [:ochameau]]

Some numbers about performance I got while reviewing https://phabricator.services.mozilla.com/D215933

Recording one click on the following page:
data:text/html,<script>window.onclick=()=>{for (let i = 0; i < 100000; i++) {foo()}}; function foo(){bar()}; function bar(){console.log("foo")};</script>
With current code using Spidermonkey Debugger API and onEnterFrame, the click handlers takes 3162ms:
https://share.firefox.dev/4cVxXuV
While, with this new "native" recording backend, it takes 1381ms:
https://share.firefox.dev/3WvsAvy
Note that it is very close to the duration without the tracer, which I measured at 1141ms.

The tracer used to introduce a 170% overhead, making the record 170% slower than original code without recording.
With the current patch queue and the new native implementation, we are now down to only 20% overhead!

Note that there is a trade-off, we have a regression when we stop the record. It can be around two times slower to collect the traces and open the profiler tab. But that's because the in-tree implementation does nothing on stop, while the new native implementation retrieve the whole data from spidermonkey and translate that into profiler data objects.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/87e647b66f2e
Implement a native backend for tracing JS execution r=arai
https://hg.mozilla.org/integration/autoland/rev/a153ad66d6d3
Output native JS trace to the profiler r=ochameau,devtools-reviewers

Comment 6

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/87e647b66f2e
https://hg.mozilla.org/mozilla-central/rev/a153ad66d6d3