1792765 - Tab freezes when running WebAssembly demo with devtools open

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, defect, P3)

Description

[Katelyn Gadd (:kael)]

Attachment: AppBundle.zip

The attached WebAssembly demo causes the tab to freeze if you click 'Render' with devtools open and the Debugger tab selected (I do this to try and capture the jitted wasm modules so I can inspect them in devtools or profile them, with no success).

It runs successfully if devtools are closed. I should also note that profiling it with the Performance tab doesn't work either, capturing the profile produces a strange error message.

The demo works fine in Chrome and Edge. You can host the demo with any local web server since it's just HTML and javascript loading a wasm module.

Comment 1

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

The severity field is not set for this bug.
:rhunt, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Ryan Hunt [:rhunt] (on leave until early May)]

The issue here is that the debugger tab forces wasm to be compiled in baseline (which is slower) with debug instrumentation added. The debug instrumentation seems to be the main issue where we insert a load+compare+branch between each wasm opcode. Commenting this out causes the render to complete in between 12 - 27seconds (not great, but not indefinite).

We have a hard set of constraints when debugging, but our implementation here is probably sub-optimal. I'll see if there's another way we could do this.

Comment 3

[Ryan Hunt [:rhunt] (on leave until early May)]

Adding some filtering to not emit duplicate breakable points (load+compare+branch) significantly improves render time. I'll see if the patch I have is landable.

Comment 4

[Ryan Hunt [:rhunt] (on leave until early May)]

Attachment: Bug 1792765 - wasm: Emit less breakpoint sites when debugging. r?yury

This eliminates 56.6% of the number of breakpoint sites when running the
linked in the bug blazor app in debugging.

Comment 5

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

The severity field is not set for this bug.
:rhunt, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Ryan Hunt [:rhunt] (on leave until early May)]

This is currently blocked on finding a way to update all the tests which assume that every bytecode offset is a valid place to put a breakpoint.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2b9f4fc135fd
wasm: Emit less breakpoint sites when debugging. r=yury

Comment 8

[Marian-Vasile Laza]

Backed out changeset 2b9f4fc135fd (Bug 1792765) for causing devtools failures on browser_dbg-features-wasm.js.
Backout link
Push with failures <--> dt1
Failure Log

Comment 9

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

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:rhunt, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.

Comment 10

[Ryan Hunt [:rhunt] (on leave until early May)]

I need to figure out how to fix the devtools test case.

Comment 11

[Ryan Hunt [:rhunt] (on leave until early May)]

https://treeherder.mozilla.org/jobs?repo=try&revision=02d5c4e1e8d388201bd285e311d720561e64616e&selectedTaskRun=Vbx31l8eQx624e9fXUZfxg.0

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1f9490d18983
wasm: Emit less breakpoint sites when debugging. r=yury

Comment 13

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/1f9490d18983