We should really do this for both parser inserted and external scripts. We only need to sync compile inline ones.

Daniel, interested to take a look?

Any luck here? :)

the "v8.compile" and "v8.run" events already correspond to two different methods on V8ScriptRunner. It would just require calling them in two tasks instead of one.

We could even split the parsing and compiling, and do the parsing on the v8 parser background thread.

I currently don't have free cycles to look at this myself, sorry

Heard from haraken that vogelheim might be working on this. Daniel, is that the case?

#7: No, am not working on this.

(As jochen says, most of this should be doable with current APIs. Making compile fully concurrent, as I think #2 suggests, would require significant effort.)

Yes, I think this is doable with current APIs. Also we just need to split the two tasks, don't need to make compile fully concurrent.

Can we find someone in the V8 team to work on this?

I was not suggesting any type of concurrent compile in #2, what I'm saying is that for a parser inserted script like:

<script>....</script>

we can execute this by doing:

1. postTask() a CompileScript task.
2. postTask() an ExecuteScript task once (1) is done.

we can do the same thing for:

<script src="thing.js"></script>

where when the bytes come back from the network we do the same two post tasks.

I know we use the ScriptStreamer thread sometimes for this too, this would be an alternative path.

The only case we need to run both steps at the same time is if you do:

script = document.createElement("script")
script.textContent = "...";
appendChild(script)

since that expects a synchronous execution of the script tag inside appendChild.

Btw, why don't we use the ScriptStreamer thread for parser inserted scripts today? We could just postTask() the bytes to the background thread... (I know the background thread is not always a win, just curious why we didn't do that.)

@haraken, no we don't currently have anybody available to work on this.

I'm interested in this!

haraken@ Do you think we could tackle this in Q1? It would help quite a bit to avoid nested iframes inserting large scripts causing jank in the main frame with long compiles, ex. AMP.

I think marja@ has been working on this.

marja@: What's the current status?

jochen@: Is it likely that someone in your team can work on this?

Elliott, you said you had somebody that might be able to look into this?

jbroman@ Said he might be interested.

I think what needs to change here is changing the code in HTMLScriptRunner::executeParsingBlockingScripts to first call compile() on each script, then execute() and always yield after each compile or execute step.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1e1d645d1cf402a63805f2106452d8d689130f1b

commit 1e1d645d1cf402a63805f2106452d8d689130f1b
Author: jbroman <jbroman@chromium.org>
Date: Wed Dec 21 01:58:22 2016

ScriptController: Expose methods to compile a script and execute a compiled script.

Simple unit tests included.

BUG=591558

Review-Url: https://codereview.chromium.org/2564903002
Cr-Commit-Position: refs/heads/master@{#439974}

[modify] https://crrev.com/1e1d645d1cf402a63805f2106452d8d689130f1b/third_party/WebKit/Source/bindings/bindings.gni
[add] https://crrev.com/1e1d645d1cf402a63805f2106452d8d689130f1b/third_party/WebKit/Source/bindings/core/v8/CompiledScript.h
[modify] https://crrev.com/1e1d645d1cf402a63805f2106452d8d689130f1b/third_party/WebKit/Source/bindings/core/v8/ScriptController.cpp
[modify] https://crrev.com/1e1d645d1cf402a63805f2106452d8d689130f1b/third_party/WebKit/Source/bindings/core/v8/ScriptController.h
[add] https://crrev.com/1e1d645d1cf402a63805f2106452d8d689130f1b/third_party/WebKit/Source/bindings/core/v8/ScriptControllerTest.cpp

Linking this doc here:
https://docs.google.com/document/d/1FarDzhLxtmBFLpuUnmWVJJxNsXR3MohnwTq0Q9f037E/edit

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e0e2dc3f7bd8b62483c2c4b8f1739158a1b05c79

commit e0e2dc3f7bd8b62483c2c4b8f1739158a1b05c79
Author: jbroman <jbroman@chromium.org>
Date: Tue Apr 25 20:52:54 2017

PendingScript: Unify watching_for_load_ with client_.

A client is "watching for load" iff it is the client of the PendingScript.
These variables are trivially redundant, and so it's simpler to just hold one.

BUG=591558

Review-Url: https://codereview.chromium.org/2840663004
Cr-Commit-Position: refs/heads/master@{#467105}

[modify] https://crrev.com/e0e2dc3f7bd8b62483c2c4b8f1739158a1b05c79/third_party/WebKit/Source/core/dom/PendingScript.cpp
[modify] https://crrev.com/e0e2dc3f7bd8b62483c2c4b8f1739158a1b05c79/third_party/WebKit/Source/core/dom/PendingScript.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ce9f0aa85bc1e34ad03dc963ef589dc3fbed21bd

commit ce9f0aa85bc1e34ad03dc963ef589dc3fbed21bd
Author: jbroman <jbroman@chromium.org>
Date: Tue May 02 16:35:29 2017

Explicitly track the lifecycle of PendingScript.

This moves the lifecycle tracking of PendingScript from relying
on querying its parts (the resource, streamer, etc.) to maintaining
an explicit state machine.

Firstly, this means that the apparent state to change is timed to
coincide with when clients are notified (as opposed to a client being
able to notice that a PendingScript is finished before being notified).

It also paves the way for additional steps (e.g. separately scheduled
compile of the script) without making IsReady and ErrorOccurred yet
more complicated.

BUG=591558

Review-Url: https://codereview.chromium.org/2828193003
Cr-Commit-Position: refs/heads/master@{#468676}

[modify] https://crrev.com/ce9f0aa85bc1e34ad03dc963ef589dc3fbed21bd/third_party/WebKit/Source/core/dom/ClassicPendingScript.cpp
[modify] https://crrev.com/ce9f0aa85bc1e34ad03dc963ef589dc3fbed21bd/third_party/WebKit/Source/core/dom/ClassicPendingScript.h