1830364 - Collect telemetry on wasm compilation sources and caching effectiveness

Status: NEW

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

Description

[Ryan Hunt [:rhunt]]

We should consider collecting telemetry on:

1. Which JS-API entry points are called to trigger compilation

• Sync or async
• Streaming or from buffer

2. Of the total compilations, how often hit a compiled cache entry
3. Of compilations that could be cached (from fetch e.g.), how often we hit a compiled cache entry

It's possible that we only need two of these and can infer the third, but it might be safe just to grab them all.

Comment 1

[Ryan Hunt [:rhunt]]

Documentation for adding a new telemetry probe is here [1]. Telemetry is a part of Gecko, not SpiderMonkey and so we need to extend the embedding layer to send this information from SM to Gecko. I think this is done here [2].

We deserialize a module from the network cache here [3]. Either that or 'execute' is called to do a normal compilation. Those two are part of CompileStreamTask which is used for compiling a module from a Web Response object. The synchronous compile options can be found by searching for wasm::CompileBuffer (some of these are testing). It's a bit of a mess.

I'd say the easiest way to implement this would be to add flags to wasm::Module for:

1. 'from cache' or 'from compiled'
2. 'from buffer' or 'from stream'

Then we can report both of those two when finishing the construction of a Module, similar to how we report a use-counter when instantiating [4].

[1] https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/start/adding-a-new-probe.html
[2] https://searchfox.org/mozilla-central/source/js/public/friend/UsageStatistics.h#20
[3] https://searchfox.org/mozilla-central/rev/d8c5478bd730644dab4336fdb83271ac1ca1d6b5/js/src/wasm/WasmJS.cpp#5079
[4] https://searchfox.org/mozilla-central/rev/d8c5478bd730644dab4336fdb83271ac1ca1d6b5/js/src/wasm/WasmModule.cpp#1127

Comment 3

[Ryan Hunt [:rhunt]]

Coming back to this again and re-reading my previous comment. I think we really need several probes:

1. 'WASM_MODULE_SOURCE' - which API did we use to create this module

• FromBuffer: https://searchfox.org/mozilla-central/rev/b19c379ba7b6d4f25af090a66cec3facf8153ee3/js/src/wasm/WasmCompile.h#51
• FromStream: https://searchfox.org/mozilla-central/rev/b19c379ba7b6d4f25af090a66cec3facf8153ee3/js/src/wasm/WasmCompile.h#97
• This will help us know how many modules we can theoretically cache.

2. 'WASM_MODULE_SIZE' - the uncompressed size of the wasm module

• It'd be great if we could correlate this with the API used to create it. I could imagine that FromBuffer could be more common with smaller byte sizes.
• We have limits on the size of module we can cache. This will help us know the % we can cache.
• Maybe we need two probes here, FROM_BUFFER_SIZE and FROM_STREAM_SIZE?