Closed Bug 1398738 Opened 2 years ago Closed 2 months ago

Discard code coverage counters when Baseline is GC-ed

Categories

(Core :: JavaScript Engine, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
mozilla71
Tracking Status
firefox71 --- fixed

People

(Reporter: nbp, Assigned: jandem)

References

(Blocks 1 open bug)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(1 file)

The interpreter can execute slowly when looking-up counters to be incremented for code coverage.  For this reason, we separated collectCoverage from collectCoverageFromDebug.

In Bug 1394761, a profile show that we do execute the code coverage code under the interpreter.

One possibility, is that the code was once hot enough to create the script counts structure, by getting compiled in Baseline, and later went unused for a while (2 GC ?), which removed the BaselineScript, leaving the function to be executed in the Interpreter again.

If we are not collecting code coverage information for debug reasons, we should trash the counters at the same time as BaselineScripts, under jit::FinishDiscardBaselineScript.
Priority: -- → P3
Bug 1437978 reported that this consumed a bit more than 1 MB on Talos.
We should ensure that we do trash them properly when we trash Baseline code (/ relazify).
Flags: needinfo?(nicolas.b.pierron)
Whiteboard: [MemShrink]
Whiteboard: [MemShrink] → [MemShrink:P2]
Flags: needinfo?(nicolas.b.pierron)
Pushed by jdemooij@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0d25043ccb59
Discard ScriptCounts after discarding JitScript. r=nbp
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Regressions: 1586485
You need to log in before you can comment on or make changes to this bug.