Sometimes we fail to unwind a complete C++ stack because we encounter a JavaScript JIT frame on the stack for which the unwinder doesn't know how to find the parent frame. This leads to profiles like this one: https://perfht.ml/2noUdGE Here it looks like we have many different invocations of the JS function "getSymbols", even though it's just one invocation. But we have different stack frames leading up to getSymbols, because some samples have complete C++ stacks and other samples do not - for those other samples we only have pseudo stack frames and JS stack frames. This can lead to a lot of confusion. In order to fix this, we'll probably need different fixes for the different platforms and unwinders we support: - macOS: On macOS we use frame pointer unwinding. So emitting frame pointers for JIT code (bug 1426134) should get us most of the way. We only have 64-bit macOS builds. - Windows 32-bit: On Windows 32-bit builds we also use frame pointer unwinding, but bug 1426134 would probably not help us because it would only emit frame pointers in 64-bit builds. - Windows 64-bit: On Windows 64-bit we use RtlVirtualUnwind to unwind the C++ call stack. This uses stack unwinding information that's stored in a side table somewhere. We would need to create such unwinding information for every piece of JIT code we compile. We do not use frame pointers for unwinding on Windows 64-bit because the compiler does not support emitting frame pointers for C++ functions on that platform. - Linux: On Linux we use LuL for unwinding, which consults both tables with unwinding information, and the frame pointer. So frame pointers in JIT code would probably solve this in 64-bit builds. We probably don't care about profiling Linux 32-bit builds. - Android/ARM: I don't know how we unwind on Android/ARM.

(In reply to Markus Stange [:mstange] from comment #0) > - Windows 32-bit: > On Windows 32-bit builds we also use frame pointer unwinding, but bug > 1426134 would probably not help us because it would only emit frame pointers > in 64-bit builds. To achieve the overall simplifications (in profiling, etc) in bug 1426134, we would probably want to just take the perf hit by preserving fp, now that it's 32.7% of our users (and probably not what we're primarily being benchmarked on). (This is what we did in wasm and it wasn't terrible; other engines also preserve fp.) > - Windows 64-bit: > On Windows 64-bit we use RtlVirtualUnwind to unwind the C++ call stack. > This uses stack unwinding information that's stored in a side table > somewhere. We would need to create such unwinding information for every > piece of JIT code we compile. > We do not use frame pointers for unwinding on Windows 64-bit because the > compiler does not support emitting frame pointers for C++ functions on that > platform. This would take extra work but if one preserves frame pointers in JIT code it's not hard to write the RtlVirtualUnwind callbacks to unwind JIT code; that's what Chakra is doing, apparently.

For what it's worth, here's a profile where the stack unwinding failed: https://perfht.ml/2I5vxie Running: <script type="text/javascript"> function a() { b(); } function b() { c(); h(); } function c() { d(); f(); } function d() { e(); } function e() { for (let i = 0; i < 1e7; i += Math.random()) {} } function f() { for (let i = 0; i < 1e7; i += Math.random()) {} g(); } function g() { for (let i = 0; i < 1e7; i += Math.random()) {} } function h() { f(); } a(); </script>

I'm also getting failures on Linux when everything is baseline. I added a `with ({}) {}` statement to every function to try and de-optimize them. I didn't get any failures on Mac, but I did on Linux. The stacks all appear to be baseline, with a couple of interpreter samples. macOS (no issue): https://perfht.ml/2Ttxecv Linux 64: https://perfht.ml/2ToHjHI I attached the code I ran.