Closed Bug 1398738 Opened 3 years ago Closed 1 year ago
Discard code coverage counters when Baseline is GC-ed
47 bytes, text/x-phabricator-request
|Details | Review|
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.
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).
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/0d25043ccb59 Discard ScriptCounts after discarding JitScript. r=nbp
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
You need to log in before you can comment on or make changes to this bug.