962412 - [meta] improve interruptibility of reflow

Status: NEW

(Core :: Layout, enhancement)

Description

[John Daggett (:jtd)]

The latest telemetry data indicates that we have cases where reflow
takes over half a second and in some cases even more than five
seconds. Assuming most of these are interruptible, we should do a
better job of interrupting these reflows to prevent chrome hangs.

The latest telemetry stats for reflow timings:
http://telemetry.mozilla.org/#nightly/29/HTML_FOREGROUND_REFLOW_MS_2

Reflow time in ms (range, count), 12/15 to 1/15 for Nightly 29:

    785    1310   1,670,000
   1310    2170     704,520
   2170    3610     335,710
   3610    6010     208,690
   6010   10000     134,230
  10000     inf     135,110
  
Total counts 71,060,000,000

While these are comparatively rare events, they would all be
classified as "chrome hang" events.

Based on a comment by bz, I put in a telemetry metric to measure how
many very long reflows (currently defined as >5000ms) are interruptible:

http://telemetry.mozilla.org/#nightly/29/LONG_REFLOW_INTERRUPTIBLE

This is a "boolean histogram" where 0 means non-interruptible and 1
means interruptible.  The data suggests that 74% of very long
reflows are interruptible.

I suspect some of these reflows are due to large text blocks, this
is a known problem (see bug 934770). But it would be a good idea to
try and come up with better metrics for determining the cause of
long running reflows and then see what we can tweak to do a better
job of interrupting reflows.

One possible solution may be to tweak the parameters used for
detecting when to interrupt reflow.  As I understand it, we only
interrupt when input events are pending and we only check for these
every nth time a call to a ReflowFrame method is called.  It might
make sense to have an absolute timeout (i.e. even if no input events
are waiting) and/or check for events more often (n = 200 currently).

The logic for checking interrupts is in nsPresContext::CheckForInterrupt:

http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresContext.cpp#2636

Comment 1

[John Daggett (:jtd)]

A number of chrome hangs have been labeled as "font" chrome hangs (see bug 859558) but many of these are better classified as "reflow hangs" in which text may or may not be a factor.  Some of these may be long reflows due to things other than just text frames:

https://bugzilla.mozilla.org/show_bug.cgi?id=859558#c5

Comment 2

[John Daggett (:jtd)]

Hmmm, given that improving interruptibility is really about preventing chrome hangs should this really be classified as an "enhancement"?  Rather than a "nice to have" I think this is a "should have" but maybe there's a layout-specific criteria for bug vs. enhancement.