IGC Slices run back to back




6 years ago
4 years ago


(Reporter: BenWa, Unassigned)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [Snappy])


(1 attachment)



6 years ago
Created attachment 661865 [details]
gc log

Focused profile: http://people.mozilla.com/~bgirard/cleopatra/?report=b2edd83b6a41cfb7dacd1d30de387a8580afdd88

As we're running through slice 3-8 they run nearly back-to-back. Is this intentional? This is blocking the tracing event from running so this has impact on responsiveness.
These GCs are being run because we're painting really often, and each repaint triggers a GC slice. I suspect there are certain repaints where we don't want to do a GC slice, but I don't know anything about the painting code. Is there a way to reproduce this? If so, we could CC some graphics people and maybe figure out the right thing to do here.

Comment 2

6 years ago
I don't have a way to reproduce this.

I think the problem here is that we have several good points to trigger a GC such as after a paint. The problem is that we can coincidentally happen to trigger several of these points in a short span. For example during an animation we can hit several paints (one every 15ms), as well we have a few messages that can force us to paint synchronously so we can end up calling js::NotifyDidPaint several times within a few milliseconds (more then every 15ms). Each of these pauses in this profile are about 11ms which is most of our frame paint budget of 15ms so we're going to miss several frames in a row.

I think the right thing to do is to enforce spacing between the IGC Slices since we have multiple things that can trigger them (http://mxr.mozilla.org/mozilla-central/source/js/src/jsfriendapi.h#670). I think all of these are good points to trigger a GC, however if most of these events happen at the same time we want to post pone the IGC Slices and rate limit them.


6 years ago
Keywords: perf


4 years ago
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.