Closed Bug 1574986 Opened 2 years ago Closed 2 years ago

GC-ubench incorrectly displays minor GCs as major GC slices

Categories

(Core :: JavaScript: GC, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox70 --- fixed

People

(Reporter: sfink, Assigned: sfink)

Details

Attachments

(2 files)

Once upon a time, we had a minor GC number, a major GC number, and a general GC number that was pretty much a major GC slice count. We use the latter GC number to detect when GC activity happened (so we might need to update pointers or invalidate some state or whatever.) But we quickly found that the general GC number needed to be bumped for minor GCs, since that is the most likely way that things would get invalidated anyway.

GC ubench still assumes that an incremented GC number means you did a GC slice, and draws a line represnting that. I've been staring at the graph recently, and I couldn't figure out what these weird standalone GCs were that never seemed to free any memory. It turns out they're just the minor GCs, but we have no way to distinguish those from GC slices that trigger a minor GC. (And I guess that means we also can't distinguish a GC slice without a minor GC from not doing anything at all!)

I will also note here that the memory display on GC ubench is lacking zone-specific triggers, and I suspect that's a large part of why the triggers aren't matching up all that well with observed behavior.

Depends on D42534

Pushed by sfink@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6cabe3bdd6ee
Comment on how GCs are determined in the GC-ubench display, and mention the missing piece of information r=jonco
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Pushed by sfink@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/883e6437a6ea
Report count of GC slices r=jonco
No longer regressions: 1604530
You need to log in before you can comment on or make changes to this bug.