Closed Bug 1364161 Opened 4 years ago Closed 4 years ago
GCMajor markers seem off
The GCMajor markers in this profile that don't seem to match up with anything in the call tree: https://perfht.ml/2pCqj07 Are we getting their time stamps wrong? The GCSlice markers seem correct, though.
Here's a profile in which the GCMajor marker seems mostly reasonable: https://perfht.ml/2qdRtfy There's a GC at the start and a GC at the end of the marker, but other runnables run in the middle.
Uh, yeah. I have GCMajor and GCSlice markers backwards. :( When a GC finishes up, it emits a GC_CYCLE_END notification, which was then producing a GCSlice marker -- but that's fine, because at the moment we suppress the final GC_SLICE_END notification. (I'm most likely going to change that, but that's irrelevant here.) When you do one slice of an incremental GC, it was producing a GCMajor marker which looks up its start/end from the first/last slice (so far). That's why it has a pile of GCMajor markers all at the same time; they're really reporting the same major GC repeatedly, once for every slice (but the last). The end times should be advancing, but they don't seem to be displayed in the UI. Doh!
Attachment #8867421 - Flags: review?(mstange)
Assignee: nobody → sphink
Status: NEW → ASSIGNED
Attachment #8867421 - Flags: review?(mstange) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/8755d3eb143b Emit a major GC marker for the end of a major GC, and a slice marker for the end of a slice, instead of the other way around, r=mstange
You need to log in before you can comment on or make changes to this bug.