It's pretty normal when looking at a JS profile in perf.html to see a bunch of hex addresses interleaved with the JS function frames. I think these are coming from the native stack walker reporting JIT frames. The actual JS frames come from the JS::ProfilingFrameIterator and get merged with the native frames using the stack address to order. But we're not throwing away the JIT frames found by the native stack walker, hence the interleaved JS->hex->JS->hex... It seems like we should be able to pretty easily filter out these hex addresses while doing the merge, and save everyone a bunch of hassle. Although the JS::ProfilingFrameIterator doesn't expose it, JitActivation contains a contiguous group of JIT stack frames and records the stack address when calling out of JIT code. JitActivation could be easily extended to also record the entry stack address and thus provide an easy way to test whether a given native frame falls within a JitActivation.
(In reply to Luke Wagner [:luke] from comment #0) > JitActivation could be easily > extended to also record the entry stack address and thus provide an easy way > to test whether a given native frame falls within a JitActivation. We can probably use the JitActivation address for this, since it's stack allocated? I'd like to avoid adding more stuff to JitActivation because it affects performance of C++ -> JIT calls.
Good point, agreed.
We could filter them out if needed in perf.html using some kind of heuristic, it just depends on what kind of behavior is desired. Are they useful to have in profiles at all, or are they just noise? I could see having transform filter that is applied by default to profiles that removes all of them, then if you want to see the data you can pop off that filter. Then if you want to re-apply it you would right click on a JIT call node, and choose "Remove JIT frames". perf.html: How to handle unsymbolicated JIT frames: https://github.com/devtools-html/perf.html/issues/586 Bug 1407662: Provide information on JIT code region in profile I'd like to have a good plan with some consensus on the best approach here.
(In reply to Greg Tatum [:gregtatum] [@gregtatum] from comment #3) > We could filter them out if needed in perf.html I would prefer to get rid of them in the profiler core itself (along the lines of Luke's proposal). We already do a bunch of stack processing (unwinding, merging) there and so that strikes me as the right place to do it. Then perf.html can continue to assume that the stacks it gets from the profiler core don't need any further cleaning up. That's all on the assumption that the relevant frames are just noise and play no useful ruole in the GUI.
Great, that sounds nice to me.
Agreed that they are just noise.
I agree. We can still store the hex addresses on the JS stack frame, if we think it's useful information. For example, once perf.html can show assembly code for C++ / rust functions, we might want to capture the generated code for JS functions in the profile, and when the user selects such a jitted JS function, show the assembly code for it. If we do that, the execution address would be needed in order to highlight the right instructions.
You need to log in before you can comment on or make changes to this bug.