791780 - IGC Slices run back to back

Status: NEW

Description

[Benoit Girard (:BenWa)]

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.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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

[Benoit Girard (:BenWa)]

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.