Profile: https://share.firefox.dev/3qKGxXG Steps to reproduce: 1. Profile a WebAssembly application (such as [this one](https://codepen.io/Coderesting/pen/YzrOOzp)) 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; "Interpreter" is just the fallback for JS functions without annotations. So we need to add an annotation for wasm frames. Interpreter and Blinterp frames are stored in the profiler label stack and their function names are known during sampling. We add them to the buffer [here](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1811) and [here](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1847-1850), respectively. 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](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1854). Later during streaming, we resolve their subcategory and implementation [here](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/ProfileBufferEntry.cpp#464-477). For wasm, it looks like we use the profiler label stack just like for Interpreter frames. So we have the function names at sampling time, and put them into the buffer with [this call to `CollectWasmFrame`](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1837). So it seems that we need to do something in `CollectWasmFrame` to record the correct subcategory and implementation.
Bug 1751279 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Profile: https://share.firefox.dev/3qKGxXG Steps to reproduce: 1. Profile a WebAssembly application (such as [this one](https://codepen.io/Coderesting/pen/YzrOOzp)) 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. And "Interpreter" is just the fallback for JS functions without annotations. So we need to add an annotation for wasm frames. Interpreter and Blinterp frames are stored in the profiler label stack and their function names are known during sampling. We add them to the buffer [here](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1811) and [here](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1847-1850), respectively. 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](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1854). Later during streaming, we resolve their subcategory and implementation [here](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/ProfileBufferEntry.cpp#464-477). For wasm, it looks like we use the profiler label stack just like for Interpreter frames. So we have the function names at sampling time, and put them into the buffer with [this call to `CollectWasmFrame`](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1837). So it seems that we need to do something in `CollectWasmFrame` to record the correct subcategory and implementation.
Profile: https://share.firefox.dev/3qKGxXG Steps to reproduce: 1. Profile a WebAssembly application (such as [this one](https://codepen.io/Coderesting/pen/YzrOOzp)) 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 and Blinterp frames are stored in the profiler label stack and their function names are known during sampling. We add them to the buffer [here](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1811) and [here](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1847-1850), respectively. 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](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1854). Later during streaming, we resolve their subcategory and implementation [here](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/ProfileBufferEntry.cpp#464-477). For wasm, it looks like we use the profiler label stack just like for Interpreter frames. So we have the function names at sampling time, and put them into the buffer with [this call to `CollectWasmFrame`](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1837). So it seems that we need to do something in `CollectWasmFrame` to record the correct subcategory and implementation.
Profile: https://share.firefox.dev/3qKGxXG Steps to reproduce: 1. Profile a WebAssembly application (such as [this one](https://codepen.io/Coderesting/pen/YzrOOzp)) 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 and their function names are known during sampling. We add them to the buffer [here](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1811). All other JS frames (Ion, Baseline, Blinterp, Wasm) come from the "JS profiling iterator" [here](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1820). 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](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1854). Later during streaming, we resolve their subcategory and implementation [here](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/ProfileBufferEntry.cpp#464-477). 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`](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1845-1850) and [this call to `CollectWasmFrame`](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1837), respectively. So it seems that we need to do something in `CollectWasmFrame` to record the correct subcategory and implementation.
Profile: https://share.firefox.dev/3qKGxXG Steps to reproduce: 1. Profile a WebAssembly application (such as [this one](https://codepen.io/Coderesting/pen/YzrOOzp)) 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](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1811). All other JS frames (Ion, Baseline, Blinterp, Wasm) come from the "JS profiling iterator" [here](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1820). 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](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1854). Later during streaming, we resolve their subcategory and implementation [here](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/ProfileBufferEntry.cpp#464-477). 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`](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1845-1850) and [this call to `CollectWasmFrame`](https://searchfox.org/mozilla-central/rev/8012bca692dddb307c2787bac1d4dd48cb0d8243/tools/profiler/core/platform.cpp#1837), respectively. So it seems that we need to do something in `CollectWasmFrame` to record the correct subcategory and implementation.