Closed Bug 1364161 Opened 3 years ago Closed 3 years ago

GCMajor markers seem off

Categories

(Core :: Gecko Profiler, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
firefox55 --- fixed

People

(Reporter: mstange, Assigned: sfink)

References

Details

Attachments

(1 file)

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.
Flags: needinfo?(sphink)
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!
Flags: needinfo?(sphink)
Assignee: nobody → sphink
Status: NEW → ASSIGNED
Attachment #8867421 - Flags: review?(mstange) → review+
Pushed by sfink@mozilla.com:
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
https://hg.mozilla.org/mozilla-central/rev/8755d3eb143b
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in before you can comment on or make changes to this bug.