Profiler baseline JIT frames lose line/column for code compiled before profiling was enabled
Categories
(Core :: JavaScript Engine: JIT, defect, P3)
Tracking
()
People
(Reporter: canova, Unassigned)
References
(Blocks 1 open bug)
Details
AddBaselineJitcodeGlobalEntry only receives a source-position table (JitCodeSourceInfo) on the compile-time path, where PerfSpewer collected the per-op line/column data while the profiler was enabled during baseline compilation.
When the profiler is enabled while baseline code is already on the stack (with the lazy / enable-time registration path), there is no PerfSpewer data available, so the BaselineEntry is registered with an empty sourceInfo_ table. As a result the sampler resolves line/column to 0 for those frames.
This is a pre-existing behavior though, the old JS::JitCodeRecord global side table had the same limitation, since it was also only populated at compile time. Bug 2044682 made it more visible by moving the table onto the entry.
To fix this we need a way to generate the native offset -> source position mapping for already-compiled baseline code at profiler-enable time, without relying on PerfSpewer having run during compilation.
Updated•2 months ago
|
Updated•2 months ago
|
Comment 1•1 month ago
|
||
It's not clear to me that this is possible without saving additional data when the profiler is disabled.
The per-op line/column data is recorded here during compilation. If we don't store it at that point, I don't see a way to recover it later without recompiling.
Description
•