1751279 - Wasm frames have the wrong subcategory and implementation (Interpreter instead of WebAssembly)

Status: RESOLVED DUPLICATE of bug 1780383

(Core :: Gecko Profiler, defect, P2)

Description

[Markus Stange [:mstange]]

Profile: https://share.firefox.dev/3qKGxXG

Steps to reproduce:

1. Profile a WebAssembly application (such as this one) or visit the profile linked above.
2. Select a wasm function in the call tree.
3. Check the subcategory and implementation in the sidebar.

Expected results:
It should say WebAssembly in both.

Actual results:
The category is "JavaScript: Interpreter" and the implementation also says "Interpreter.".

---

We get this right for JS functions running in Ion, Baseline or BaselineInterpreter - those have the correct "implementation", and also the right subcategory as of bug 1645469. And "Interpreter" is just the fallback for JS functions without annotations. So we need to add an annotation for wasm frames.

Interpreter frames are stored in the profiler label stack; their function names are resolved and put into the profiler label stack when the function is entered. We add Interpreter frames to the buffer here.

All other JS frames (Ion, Baseline, Blinterp, Wasm) come from the "JS profiling iterator" here.

Ion and Baseline frames are stored as code addresses ("JitReturnAddr") and their function names are only looked up during "streaming", i.e. during JSON serialization. We add their addresses to the buffer here. Later during streaming, we resolve their subcategory and implementation here.

For blinterp and wasm, it looks like we have the function names at sampling time, and we don't do any delayed lookup. We put them into the buffer with this call to CollectProfilingStackFrame and this call to CollectWasmFrame, respectively.

So it seems that we need to do something in CollectWasmFrame to record the correct subcategory and implementation.

Comment 1

[Markus Stange [:mstange]]

It's probably only worth fixing the subcategory here.

The implementation is also wrong for blinterp frames, and the "implementation" concept may soon go away entirely, depending on what we decide on in https://github.com/firefox-devtools/profiler/issues/3713.

Comment 2

[Mayank Bansal]

Dupe of bug 1780383 ?

Comment 3

[Markus Stange [:mstange]]

Oh, indeed. Looks like I failed to CC the right people here.

Comment 4

[Jan de Mooij [:jandem]]

Hah, I had no idea this was already on file. We also ended up with the same fix :-)