1507939 - Add "verbose" pref to spew wasm stats to console

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, enhancement)

Description

[Luke Wagner [:luke]]

I always appreciated the "Successfully compiled asm.js" warnings in the console b/c it was a quick way to see if asm.js was being used and get a few stats, and I miss it for wasm.  Currently, to see if wasm is used, I look in about:memory for WebAssembly objects, but that's not great.

It'd be great to add an about:config pref that prints on every: compilation, instantiation, memory creation, with full stats (e.g., which custom sections were validated).  I often have to do a custom build with printf()s to get this data, so this could save us all a bunch of time and expedite triage.

This came up in the context of https://github.com/WebAssembly/tool-conventions/pull/65#issuecomment-439527548, where I was realizing that a producer would really love to get a confirmation that they generated the right thing.

Comment 1

[Sven Sauleau]

I second this, the warning is quite useful.

In Chrome's developer toolbar there's an "Application" tab which shows service workers status for example. I could imagine the same for WebAssembly, with some perf information you mentioned and showing the producer section.
I couldn't find an equivalent tab in the Firefox debugger.

Comment 2

[Luke Wagner [:luke]]

Attachment: wasm-verbose (WIP)

I started a patch on the plane, still WIP.  At the moment, this would just print to the web console as a warning, like the old asm.js messages.

Comment 3

[Luke Wagner [:luke]]

Attachment: fix-style

Fix some style butchered by clang-format.  The patch reorders a few fields so the comments read in a nicer order.  The comment before the block in the `case Tail:` prevents the goofy styling bug.

Comment 4

[Luke Wagner [:luke]]

Attachment: wasm-verbose

Here's an initial version.  Comments welcome if anything else is obviously high-value.

Comment 5

[Lars T Hansen [:lth]]

Comment on attachment 9032604 [details] [diff] [review]
fix-style

Review of attachment 9032604 [details] [diff] [review]:
-----------------------------------------------------------------

Nice.

Comment 6

[Lars T Hansen [:lth]]

Comment on attachment 9032605 [details] [diff] [review]
wasm-verbose

Review of attachment 9032605 [details] [diff] [review]:
-----------------------------------------------------------------

Other cases I can think about would normally show up in a backtrace resulting from an unhandled exception.  I guess in principle every violation of an implementation limit (documented or not) warrants a log message; sounds like followup work, mainly.

::: js/src/wasm/WasmJS.cpp
@@ +2979,5 @@
>    }
>  
> +  if (error) {
> +    MOZ_ASSERT(!validated);
> +    Log(cx, "validate() failed with: %s", error.get());

At long last :)

Comment 7

[Lars T Hansen [:lth]]

Comment on attachment 9032605 [details] [diff] [review]
wasm-verbose

Review of attachment 9032605 [details] [diff] [review]:
-----------------------------------------------------------------

Other cases I can think about would normally show up in a backtrace resulting from an unhandled exception.  I guess in principle every violation of an implementation limit (documented or not) warrants a log message; sounds like followup work, mainly.

::: js/src/wasm/WasmJS.cpp
@@ +2979,5 @@
>    }
>  
> +  if (error) {
> +    MOZ_ASSERT(!validated);
> +    Log(cx, "validate() failed with: %s", error.get());

At long last :)

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c4401229d95d
Baldr: fix some style formatting issues (r=lth)
https://hg.mozilla.org/integration/mozilla-inbound/rev/e99c9b3af385
Baldr: add javascript.options.wasm_verbose (r=lth)

Comment 9

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/c4401229d95d
https://hg.mozilla.org/mozilla-central/rev/e99c9b3af385

Comment 10

[Benjamin Bouvier [:bbouvier] (inactive)]

Nice job!

Would it make sense to add more information like:

- the time it took to compile a module with each tier? (not only to show off, but to detect extreme cases in the wild, or to make new backends benchmarking trivial)
- which tier was used during compilation? It would be useful to me at least, since I've had cases where I've wanted to measure ion/cranelift, and I was actually measuring/forgetting about baseline.
- and also when the switch to the second tier happened?

Comment 11

[Luke Wagner [:luke]]

Yes, it makes sense to add all these.  In this bug I just wanted to lay down some initial bits and then we can fill in more as we see them become useful.

Comment 12

[Lars T Hansen [:lth]]

Ditto. There's some prototype code for computing these values now hanging off bug 1496325, I want to report these values via telemetry too. We should coordinate where it makes sense.