Contact emails
tz...@chromium.org, schedu...@chromium.org, platform-arc...@chromium.org
Explainer
Cooperative Scheduling makes long running third party JS tasks to yield the main thread for the renderer responsiveness. This change itself doesn’t add or update any API or spec, but changes the internal task execution semantics within the UA discretion.
Design doc/Spec
Design doc: Cooperative Scheduling.
Summary
Stop V8 execution at certain safepoints, and run a nested message loop for better responsiveness when a long running task from a third party iframe blocks the renderer main thread. To do it safely and spec compliant, we’ll reorganize schedulers and task queues into EventLoop, and introduce opt-in scope to manage reentrancy as described in the design doc.
Motivation
Improving the renderer responsiveness is the motivation. Long running tasks block the main thread, that stops all other contents that share the same main thread.
Risks
Interoperability and Compatibility
We consider there’s no risk, as Cooperative Scheduling modifies no spec nor API, and the change is within the UA discretion.
Ergonomics
Cooperative Scheduling introduces an opt-in scope for running a nested message loop. We have to keep the call path around the scope reentrant.
Activation
N/A. Web developers need no action for this.
Debuggability
N/A.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
No. This feature targets Android only at least as the first target.
OOPIF (Out Of Process IFrame) should work fine for desktop browsers instead of Cooperative Scheduling.
Link to entry on the feature dashboard
N/A.
Requesting approval to ship?
No for now. We’ll implement it behind a flag.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFK_eqQOzc7cU0QuRMbiJ_Ywcgn2TYaQNdOv6szWAbMFeMAFow%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jzL8kDd8ZHuwcrt42H2inpYVZxWjmwHgX8QEtF7M-0t9Q%40mail.gmail.com.
On 2/2/18 12:56 AM, Kentaro Hara wrote:
Mozilla already shipped <https://hacks.mozilla.org/2017/06/an-inside-look-at-quantum-dom-scheduling/> the cooperative scheduling as part of the Quantum project.
Just to be clear, that blog post describes proposed work in progress. We (Mozilla) are not in fact shipping cooperative scheduling so far, and it's unclear that we will be at all, given initial measurements.
Not that this should affect what Chrome does, but I figured I'd set the record straight on what Mozilla is doing. ;)
-Boris
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6c96f4f4-63e2-5f1c-5c64-42d080b0278e%40mit.edu.
And once site isolation happens, the potential wins here need to be reevaluated, of course.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jxfR5TbO7ABwvvk_BaoAsZwB344dq3KJJnuUMNuEnpYNw%40mail.gmail.com.
Cooperative scheduling sounds like a great way to localize performance on mobile!However, I'm very scared of nested message loops (we've had a great deal of problems with them already in the scheduler) and I'd like to avoid increasing their usage in Chromium by a magnitude.What we want to do here is to implement user-space execution context switching. I wonder if instead using message loops we could implement it using coroutine-like approach by saving the stack state using setjmp/longjmp and yielding control back to the scheduler?The benefits include reduced number of problems with reentrancy and explicit control of the execution flow from the scheduler (e.g. better control when we can resume execution of an interrupted task).
The other issue that this approach addresses is security -- this way we won't end up with frames both from main frame and cross-origin iframe on the same stack.+alexclarke@, skyostil@, gab@ and scheduler-dev@.
P. S. I'd say that this has low to medium compat risks -- at the moment web developers do not expect that their scripts can be interrupted in the middle and this can break some metrics and analytics. It's likely that we'll have to expose some information about preemption to web devs.
--On 2 February 2018 at 16:38, Kentaro Hara <har...@chromium.org> wrote:Thanks Boris!--And once site isolation happens, the potential wins here need to be reevaluated, of course.Yeah, our plan is to have both OOPIF and cooperative scheduling. For example, it would be hard to enable OOPIF on low-memory mobile devices. Even on desktops it's not uncommon that one renderer process is shared by multiple tabs. My assumption is that the cooperative scheduling would be useful for those scenarios. In other words, the cooperative scheduling is expected to solve jank issues that cannot be solved by OOPIF :)On Sat, Feb 3, 2018 at 1:20 AM, Boris Zbarsky <bzba...@mit.edu> wrote:On 2/2/18 10:15 AM, Kentaro Hara wrote:
I'm just curious but does this mean that you didn't get a clear performance win (if you don't mind sharing it)?
I haven't been following this closely, but my impression is that at least for the moment the ratio of potential wins (that would be the initial measurements) to engineering effort is less than for other things we can work on, so we're focusing on those.
And once site isolation happens, the potential wins here need to be reevaluated, of course.
-Boris
--Kentaro Hara, Tokyo, Japan
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jxfR5TbO7ABwvvk_BaoAsZwB344dq3KJJnuUMNuEnpYNw%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.
To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CALHg4nmCqhtY9%2BOb%2BojR9JySvVMiikXSw8tKKtWLD-oa7q4zbw%40mail.gmail.com.
However, I'm very scared of nested message loops (we've had a great deal of problems with them already in the scheduler) and I'd like to avoid increasing their usage in Chromium by a magnitude.
On Fri, Feb 2, 2018 at 10:50 AM Alexander Timin <alt...@chromium.org> wrote:Cooperative scheduling sounds like a great way to localize performance on mobile!However, I'm very scared of nested message loops (we've had a great deal of problems with them already in the scheduler) and I'd like to avoid increasing their usage in Chromium by a magnitude.What we want to do here is to implement user-space execution context switching. I wonder if instead using message loops we could implement it using coroutine-like approach by saving the stack state using setjmp/longjmp and yielding control back to the scheduler?The benefits include reduced number of problems with reentrancy and explicit control of the execution flow from the scheduler (e.g. better control when we can resume execution of an interrupted task).From my understanding of the proposal, we don't allow unlimited re-entrancy. I'd also be quite nervous about setjmp() and longjmp() and how they interact with things like RAII and destructors.
The other issue that this approach addresses is security -- this way we won't end up with frames both from main frame and cross-origin iframe on the same stack.+alexclarke@, skyostil@, gab@ and scheduler-dev@.I'm not sure how setjmp() and longjmp() would help with this: the state I'd be most concerned about is global state (e.g. what is the current execution context).
P. S. I'd say that this has low to medium compat risks -- at the moment web developers do not expect that their scripts can be interrupted in the middle and this can break some metrics and analytics. It's likely that we'll have to expose some information about preemption to web devs.I don't think this would break things any more than OOPIF would, since a context can only yield to a cross-site context.Daniel
--On 2 February 2018 at 16:38, Kentaro Hara <har...@chromium.org> wrote:Thanks Boris!--And once site isolation happens, the potential wins here need to be reevaluated, of course.Yeah, our plan is to have both OOPIF and cooperative scheduling. For example, it would be hard to enable OOPIF on low-memory mobile devices. Even on desktops it's not uncommon that one renderer process is shared by multiple tabs. My assumption is that the cooperative scheduling would be useful for those scenarios. In other words, the cooperative scheduling is expected to solve jank issues that cannot be solved by OOPIF :)On Sat, Feb 3, 2018 at 1:20 AM, Boris Zbarsky <bzba...@mit.edu> wrote:On 2/2/18 10:15 AM, Kentaro Hara wrote:
I'm just curious but does this mean that you didn't get a clear performance win (if you don't mind sharing it)?
I haven't been following this closely, but my impression is that at least for the moment the ratio of potential wins (that would be the initial measurements) to engineering effort is less than for other things we can work on, so we're focusing on those.
And once site isolation happens, the potential wins here need to be reevaluated, of course.
-Boris
--Kentaro Hara, Tokyo, Japan
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jxfR5TbO7ABwvvk_BaoAsZwB344dq3KJJnuUMNuEnpYNw%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.
To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CALHg4nmCqhtY9%2BOb%2BojR9JySvVMiikXSw8tKKtWLD-oa7q4zbw%40mail.gmail.com.