Using microtask checkpoints for resetting the slow script dialog timer

[Boris Zbarsky]

Right now we use the ScriptEvaluated call to reset the "time we have
been running script" state. This requires us to have hacks for modal
state in there, and still has problems if we bounce in and out of
scripts (like event listeners, say) each of which is quick but which
cumulatively take lots of time.

Would it make any sense to reset the timer off a microtask checkpoint
instead? So conceptually we'd do it like so:

1) A call to the operation callback records the current time if we're
in the "reset" state.
2) Following calls compare the "now" time to the recorded time and put
up the slow script dialog as needed.
3) Clicking "stop script" disables script on the page (so if this
happens inside an event listener, that will not run any more script
for that event dispatch).
4) A microtask checkpoint resets our state and reenables script if it
was disabled due to item 3. Probably after doing the mutation
handlers and whatnot.

Thoughts?

-Boris

[Bobby Holley]

Yeah, ScriptEvaluated is totally wonky and needs to go away.

I've always been really wary of microtasks though - it seems like one of
those magic things that we sprinkle everywhere (like requests and unmarking
gray) that we're generally moving away from.

What about tying it to script entry points? Are they roughly isomorphic, or
are there important divergences?

bholley

[Boris Zbarsky]

On 7/10/13 5:09 PM, Bobby Holley wrote:
> I've always been really wary of microtasks though - it seems like one of
> those magic things that we sprinkle everywhere (like requests and unmarking
> gray) that we're generally moving away from.

Microtasks are clearly defined in the spec, is the idea, so we shouldn't
have any issues in terms of where microtask checkpoints happen.

Basically there are two places they happen: when the JS stack completely
unwinds and when the event loop spins.

> What about tying it to script entry points? Are they roughly isomorphic, or
> are there important divergences?

There are important divergences. If I do a dispatchEvent, there is a
script entry point for each event listener that fires, but we don't
really want to be resetting the slow script timer each time an event
listener completes, I believe. That's basically the setup we have right
now and one I'd like to move away from.

-Boris

[Bobby Holley]

On Wed, Jul 10, 2013 at 2:16 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> Microtasks are clearly defined in the spec, is the idea, so we shouldn't
> have any issues in terms of where microtask checkpoints happen.
>
> Basically there are two places they happen: when the JS stack completely
> unwinds and when the event loop spins.

Ok. They seem pretty wack-a-mole in Gecko, though.

There are important divergences. If I do a dispatchEvent, there is a
> script entry point for each event listener that fires, but we don't really
> want to be resetting the slow script timer each time an event listener
> completes, I believe. That's basically the setup we have right now and one
> I'd like to move away from.

But CallbackObject constructs an AutoMicroTask, right? So doesn't that lend
us to the same problem? Or is the idea that the 'checkpoint' only happens
when the microtask depth hits zero? If so, how do we handle nested event
loops?

bholley

[Boris Zbarsky]

On 7/11/13 1:15 AM, Bobby Holley wrote:
> Ok. They seem pretty wack-a-mole in Gecko, though.

To the extent that the concept of "unwind the stack" is a bit
whack-a-mole, yeah. I'm not saying it couldn't be better. ;)

> But CallbackObject constructs an AutoMicroTask, right? So doesn't that lend
> us to the same problem? Or is the idea that the 'checkpoint' only happens
> when the microtask depth hits zero?

Yes, exactly.

> If so, how do we handle nested event loops?

By doing a checkpoint when the event loop spins, like the spec requires.
See nsXPConnect::AfterProcessNextEvent. Note that the only thing we
do off a microtask checkpoint right now is
nsDOMMutationObserver::HandleMutations.

-Boris

[Bobby Holley]

On Wed, Jul 10, 2013 at 10:36 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> To the extent that the concept of "unwind the stack" is a bit
> whack-a-mole, yeah. I'm not saying it couldn't be better. ;)

Ok. Could we make this better by tying it to the 0<->1 transition in
request depth on the runtime? That should more or less correspond with the
first cx we push, which should give us a much more reliable answer.

> But CallbackObject constructs an AutoMicroTask, right? So doesn't that lend
> us to the same problem? Or is the idea that the 'checkpoint' only happens
> when the microtask depth hits zero?
>

Yes, exactly.

What are the situations where the stack completely unwinds but we don't
spin the top-level event loop?

bholley

[Boris Zbarsky]

On 7/11/13 1:43 AM, Bobby Holley wrote:
> Ok. Could we make this better by tying it to the 0<->1 transition in
> request depth on the runtime? That should more or less correspond with the
> first cx we push, which should give us a much more reliable answer.

I'm not sure we can; microtasks might need to span execution with no JS
on the stack. Olli would know for sure...

> What are the situations where the stack completely unwinds but we don't
> spin the top-level event loop?

For us right now, or in general?

Here's an example: it's not clear to whether a refresh driver tick
should have one microtask around all the requestAnimationFrame callbacks
or not. Right now we do not, but maybe we should.

But more to the point, exactly what constitutes a microtask will be
specced, and seems to align well with how the slow script dialog should
work, to me.

-Boris

[Boris Zbarsky]

On 7/11/13 2:04 AM, Boris Zbarsky wrote:
> But more to the point, exactly what constitutes a microtask will be
> specced, and seems to align well with how the slow script dialog should
> work, to me.

Hmm... Though I suppose it's possible that the spec could define on
microtask per requestAnimationFrame callback while we want to have the
slow-script timer consider all the callbacks for a single refresh driver
tick together...

I guess the other problem is to just reset the slow script state when we
spin the event loop. That should help with the real problem we're
trying to solve, which is being away from the event loop for too long,
right?

-Boris

[smaug]

Event handling. If you have several event listeners, microtask check point is after each of those.

>
> bholley
>