Skip to content

Give the frameTable a lib column - #6258

Open
mstange wants to merge 1 commit into
firefox-devtools:mainfrom
mstange:push-punossrmnotm
Open

Give the frameTable a lib column#6258
mstange wants to merge 1 commit into
firefox-devtools:mainfrom
mstange:push-punossrmnotm

Conversation

@mstange

@mstange mstange commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Main | Deploy preview

In the past, the way to get the library for a frame would be to go frame -> func -> resource -> lib. For native frames, the resource is of type Library and points at the lib.

This had the following implications:

  • Native frames cannot ever have a resource of a non-Library type.
  • If two native frames want to share a func, they must also share the same library - otherwise they'll be in a different resource, and different resource means different func.

This makes it hard to represent a few cases:

  • JS JIT frames with assembly. To have assembly, we must have a native library, but we also want JIT frames to have a JS file as their resource, and we want JITted frames for a JS function to share the func with non-JITted frames (interpreter frames) of the same JS function.
  • Comparison profiles / the "diff" thread for different builds, with assembly code. For example if you have two Firefox builds, one with and one without a patch, they'll have different libxul.so libraries, but you still want to combine C++ functions of the same name in the diffed tree.
  • Resources for Rust crates (not implemented here): We might want to assign different Rust frames from the same native binary to different resources, with one resource per Rust crate.

This commit makes it so that frames now point at their library directly, and removes the lib column from the resourceTable. A resource of type Library only carries the library's name; several libs can share one.

mergeLibs used to key on name + debugName, which collapsed two builds of the same library into one lib (and one resource). Now it keeps the libs separate but still collapses the resources by name.

For func-only contexts there is no longer a func -> lib edge. formatFunctionNameWithLibrary and the new getLibNameForFunc read the name off the func's resource, which is all they ever needed. profile-query's functionInfo, which wants the full Lib record, scans the frame table once per query.

@codecov

codecov Bot commented Aug 12, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 88.46154% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.76%. Comparing base (1198e50) to head (ea3fdb5).
⚠️ Report is 39 commits behind head on main.

Files with missing lines Patch % Lines
src/profile-query/function-list.ts 42.85% 8 Missing ⚠️
src/profile-logic/bottom-box.ts 70.00% 3 Missing ⚠️
src/profile-query/index.ts 0.00% 3 Missing ⚠️
src/profile-logic/symbolication.ts 96.22% 2 Missing ⚠️
src/profile-query/formatters/marker-info.ts 80.00% 1 Missing ⚠️
src/profile-query/formatters/thread-info.ts 80.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #6258      +/-   ##
==========================================
+ Coverage   83.73%   83.76%   +0.02%     
==========================================
  Files         350      350              
  Lines       37523    37569      +46     
  Branches    10543    10564      +21     
==========================================
+ Hits        31420    31468      +48     
+ Misses       5676     5674       -2     
  Partials      427      427              

☔ View full report in Codecov by Harness.
📢 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.

@mstange
mstange force-pushed the push-punossrmnotm branch 3 times, most recently from 11a13fb to a2d6fdc Compare August 12, 2026 21:46
In the past, the way to get the library for a frame would be to go
frame -> func -> resource -> lib. For native frames, the resource is
of type Library and points at the lib.

This had the following implications:

- Native frames cannot ever have a resource of a non-Library type.
- If two native frames want to share a func, they must also share the
  same library - otherwise they'll be in a different resource, and
  different resource means different func.

This makes it hard to represent a few cases:

- JS JIT frames with assembly. To have assembly, we must have a native
  library, but we also want JIT frames to have a JS file as their
  resource, and we want JITted frames for a JS function to share the
  func with non-JITted frames (interpreter frames) of the same JS function.
- Comparison profiles / the "diff" thread for different builds, with
  assembly code. For example if you have two Firefox builds, one with and
  one without a patch, they'll have different libxul.so libraries, but
  you still want to combine C++ functions of the same name in the diffed
  tree.
- Resources for Rust crates (not implemented here): We might want to assign
  different Rust frames from the same native binary to different resources,
  with one resource per Rust crate.

This commit makes it so that frames now point at their library directly,
and removes the lib column from the resourceTable. A resource of type
Library only carries the library's name; several libs can share one.

mergeLibs used to key on name + debugName, which collapsed two builds of
the same library into one lib (and one resource). Now it keeps the libs
separate but still collapses the resources by name.

For func-only contexts there is no longer a func -> lib edge.
formatFunctionNameWithLibrary and the new getLibNameForFunc read the name
off the func's resource, which is all they ever needed. profile-query's
functionInfo, which wants the full Lib record, scans the frame table once
per query.
@mstange
mstange force-pushed the push-punossrmnotm branch from a2d6fdc to ea3fdb5 Compare August 12, 2026 21:48
@mstange
mstange marked this pull request as ready for review August 12, 2026 21:48
@mstange
mstange requested a review from canova August 12, 2026 21:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant