Consider building macOS non-Nightly with frame pointers, for more useful profiling and more
Categories
(Core :: Gecko Profiler, enhancement, P2)
Tracking
()
People
(Reporter: mozbugz, Unassigned)
Details
On macOS, frame pointers are necessary to record backtraces, but they are only available on Nightly. This means that Beta and Release cannot capture stack traces.
The downsides of adding frame pointers may include: Bigger executable, loss of performance.
It would be good to start with taking measurements about these, and if they appear small enough, it could be worth the cost to allow better profiles and other backtrace-based features (BHR, crashes, etc.)
Comment 1•3 years ago
|
||
Any reason not to use unwind info instead?
Comment 2•3 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #1)
Any reason not to use unwind info instead?
I think Markus will have answers to this question.
Comment 3•3 years ago
|
||
Huh, isn't this bug a duplicate of bug 1451902?
(In reply to Mike Hommey [:glandium] from comment #1)
Any reason not to use unwind info instead?
A bunch of reasons:
- We currently don't have a stackwalker for macOS which supports unwind info.
- Even if we added macOS support to Lul, we'd take a massive profiler startup performance hit. We already have this hit on Linux and Android arm64, and it's a big problem (bug 1635810).
- Frame pointer stackwalking is dead simple and fast.
- Unwind info stackwalking is not supported by Activity Monitor "Sample Process" or even Instruments, from what I can tell.
- All regular macOS apps have frame pointers enabled. It's the default build configuration.
- We don't have 32 bit builds on macOS, so register pressure is less of a concern.
- For arm64 specifically, having frame pointers enabled is requested by Apple's arm64 guidelines. On those machines we also have even more registers available.
The Rust compiler's default --release configuration also enables frame pointers everywhere, as of https://github.com/rust-lang/rust/pull/85706.
Comment 4•3 years ago
|
||
So why do it on mac only?
Comment 5•3 years ago
•
|
||
We currently don't have a stackwalker for macOS which supports unwind info.
FWIW, MozStackWalk uses libunwind on mac.
Comment 6•3 years ago
•
|
||
(In reply to Mike Hommey [:glandium] from comment #4)
So why do it on mac only?
I'd love to do it everywhere! Doing it on mac-only seemed like an easier subset.
(In reply to Mike Hommey [:glandium] from comment #5)
We currently don't have a stackwalker for macOS which supports unwind info.
FWIW, MozStackWalk uses libunwind on mac.
Interesting. We don't use MozStackWalk in the profiler, as far as I know. And it looks like it can only unwind the current thread, whereas the profiler needs the ability to walk the stacks of other threads, from the profiler's sampler thread.
Edit: It looks like, for Windows only, we have a MozStackWalkThread function which takes a thread HANDLE.
Updated•3 years ago
|
Description
•