Propagate isJS to symbolicated funcs

[mstange]

I'm currently testing a mode in samply where native symbolication supplies the name for JS functions. This means that we now have frames which are both "JS" and "native" at the same time - they should be visible in the JS-only call tree, but they also have a native library and an address and can get their names by symbolicating an address.

One thing I noticed is that, when symbolication has to add new funcs to the func table, these funcs always had isJS == false. But when symbolicating JS frames via native symbolication, we actually want to propagate isJS from the unsymbolicated function.

Here's a badly-symbolicated example: https://share.firefox.dev/4d0sYMp
The function intersect disappears in JS-only mode.

(The above profile also demonstrates inline symbolication but I realize now that the actual bug doesn't require inlining at all.)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.44%. Comparing base (9b8f99f) to head (23f14bf).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5907      +/-   ##
==========================================
+ Coverage   85.42%   85.44%   +0.02%     
==========================================
  Files         321      321              
  Lines       32162    32164       +2     
  Branches     8875     8781      -94     
==========================================
+ Hits        27473    27483      +10     
+ Misses       4253     4245       -8     
  Partials      436      436              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[canova]

I'm currently testing a mode in samply where native symbolication supplies the name for JS functions. This means that we now have frames which are both "JS" and "native" at the same time - they should be visible in the JS-only call tree, but they also have a native library and an address and can get their names by symbolicating an address.

Oh that's very interesting. Which frames are going to be both? Like some JIT frames etc? For example, what is intersect exactly in the example profile you shared? I remember wanting to have something similar for the gecko profiler, I don't remember for which one yet though...

Overall, I think it makes perfect sense to preserve the existing isJS flag. Thanks!

[mstange]

Oh that's very interesting. Which frames are going to be both? Like some JIT frames etc?

Yes, exactly, JIT frames.

For example, what is intersect exactly in the example profile you shared?

It's a JS function that was jitted. During native stack walking, we found a return address that was inside its JIT code, so we turned it into a "frame with a library and an address" (the library being the synthetic JIT library we create for jitdump files). And then the symbol information from the jitdump file gives us the function name, and any inlined JS functions once we add jitdump support for that. samply here is actually looking up the function name in the jitdump file twice: First, when it puts the stack into the profile, because that's when it needs to mark the frame as "isJS". And then again when it responds to the symbolication request. Maybe we'll want the symbolication response to say "this frame is a JS frame" in the future so that we can save the first lookup.