Add V8 platform API to call delayed task.

Add V8 platform API to call delayed task.

Delayed tasks can be used to perform non-urgent clean up work.

BUG=chromium:490559
LOG=NO

Committed: https://crrev.com/31e3177bb01fbe2b0a1e2a08dc82165ee6fbe692
Cr-Commit-Position: refs/heads/master@{#29084}

[ulan, 2015-06-12 13:39:36]

ulan@chromium.org changed reviewers:
+ jochen@chromium.org, rmcilroy@chromium.org

[ulan, 2015-06-12 13:42:42]

PTAL.

[rmcilroy, 2015-06-15 10:29:17]

For your description /s/not urgent/non-urgent/.  

Also, you say you can post clean up work such as idle-time GC as delayed work,
however you shouldn't do this as it isn't guaranteed that the browser will be
idle when the delayed work becomes runnable. What you would need to do is post a
small task which itself posts an idle task (if required) when it get's run? If
so you should probably make this clearer on the description.

Talking of which, you will need a postIdleTask API as well - are you doing that
as a separate CL? It might make sense just to do it here.

https://codereview.chromium.org/1179153002/diff/1/src/libplatform/default-pla...
File src/libplatform/default-platform.cc (right):

https://codereview.chromium.org/1179153002/diff/1/src/libplatform/default-pla...
src/libplatform/default-platform.cc:113: task =
PopTaskInMainThreadDelayedQueue(isolate);
This could lead to starvation of the delayed queue (e.g., if the task popped on
the main queue always posted another non-delayed task then the delayed queue
would never get a chance to run. It would be better to flush all "runnable"
tasks from the delayed queue onto the non-delayed queue when they become
eligible to be run, and then pop a task of the non-delayed queue.

[ulan, 2015-06-15 14:52:54]

> For your description /s/not urgent/non-urgent/.  
Done.

> Also, you say you can post clean up work such as idle-time GC as delayed work,
> however you shouldn't do this as it isn't guaranteed that the browser will be
> idle when the delayed work becomes runnable. What you would need to do is post
a
> small task which itself posts an idle task (if required) when it get's run? 

Sorry, the description was confusing. I removed reference to "idle GC".
I think the confusion comes from the two meanings of "idle":
1. compositor is idle: we get IdleNotification or task posted with
postIdleTask() is called.
2. mutator is idle: very low allocation throughput.
I was referring to the second idleness, i.e. a delayed task initiates an
incremental GC if there is a lot of garbage and allocation throughput is low.
This would allow us to remove ad-hoc logic from IdleGCHandler and simplify
IdleNotification (the reduce memory mode will be gone).

How the incremental steps are performed is different issue. For now, doing the
steps in the IdleNotification would work. Eventually we want to use
postIdleTask() to post many small idle tasks and get rid of IdleNofitication
completely as we discussed earlier in chat.

Since implementing postIdleTask in V8Platform in Chromium seems to require a lot
of plumbing and will take some time, I wanted to quickly finish postDelayedTask
(few lines of code in Chromium) and then tackle postIdleTask in separate CLs.

The main issue with postIdleTask is layering. Chromium implements V8Platform in
base::gin, which uses base::SingleThreadTaskRunner, but postIdleTask lives in
scheduler::SingleThreadIdleTaskRunner. The base doesn't know about idle tasks
and cannot directly include scheduler, so we need hooks in the ::base for the
postIdleTask.

https://codereview.chromium.org/1179153002/diff/1/src/libplatform/default-pla...
File src/libplatform/default-platform.cc (right):

https://codereview.chromium.org/1179153002/diff/1/src/libplatform/default-pla...
src/libplatform/default-platform.cc:113: task =
PopTaskInMainThreadDelayedQueue(isolate);
On 2015/06/15 10:29:17, rmcilroy wrote:
> This could lead to starvation of the delayed queue (e.g., if the task popped
on
> the main queue always posted another non-delayed task then the delayed queue
> would never get a chance to run. It would be better to flush all "runnable"
> tasks from the delayed queue onto the non-delayed queue when they become
> eligible to be run, and then pop a task of the non-delayed queue.
Good point and awesome solution! :) Added flushing of delayed queue.

[rmcilroy, 2015-06-15 17:36:36]

On 2015/06/15 14:52:54, ulan wrote:
> > For your description /s/not urgent/non-urgent/.  
> Done.
> 
> > Also, you say you can post clean up work such as idle-time GC as delayed
work,
> > however you shouldn't do this as it isn't guaranteed that the browser will
be
> > idle when the delayed work becomes runnable. What you would need to do is
post
> a
> > small task which itself posts an idle task (if required) when it get's run? 
> 
> Sorry, the description was confusing. I removed reference to "idle GC".
> I think the confusion comes from the two meanings of "idle":
> 1. compositor is idle: we get IdleNotification or task posted with
> postIdleTask() is called.
> 2. mutator is idle: very low allocation throughput.
> I was referring to the second idleness, i.e. a delayed task initiates an
> incremental GC if there is a lot of garbage and allocation throughput is low.
> This would allow us to remove ad-hoc logic from IdleGCHandler and simplify
> IdleNotification (the reduce memory mode will be gone).
> 
> How the incremental steps are performed is different issue. For now, doing the
> steps in the IdleNotification would work. Eventually we want to use
> postIdleTask() to post many small idle tasks and get rid of IdleNofitication
> completely as we discussed earlier in chat.

Makes sense, thanks.

> Since implementing postIdleTask in V8Platform in Chromium seems to require a
lot
> of plumbing and will take some time, I wanted to quickly finish
postDelayedTask
> (few lines of code in Chromium) and then tackle postIdleTask in separate CLs.
> 
> The main issue with postIdleTask is layering. Chromium implements V8Platform
in
> base::gin, which uses base::SingleThreadTaskRunner, but postIdleTask lives in
> scheduler::SingleThreadIdleTaskRunner. The base doesn't know about idle tasks
> and cannot directly include scheduler, so we need hooks in the ::base for the
> postIdleTask.

Ahh yes, I forgot that this would be being implemented in gin not blink, so the
layering requirements are different. Makes sense, let me know if I can help with
moving the necessary APIs to base (if all you need is
scheduler::SingleThreadIdleTaskRunner in base then hopefully that shouldn't be
too difficult).

lgtm, thanks.

[jochen (gone - plz use gerrit), 2015-06-16 08:42:22]

lgtm

[ulan, 2015-06-16 13:40:47]

The CQ bit was checked by ulan@chromium.org

[commit-bot: I haz the power, 2015-06-16 13:40:57]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1179153002/20001

[commit-bot: I haz the power, 2015-06-16 13:50:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-16 13:50:38]

Try jobs failed on following builders:
  v8_linux_chromium_gn_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_chromium_gn_rel/bu...)

[ulan, 2015-06-16 14:30:32]

The CQ bit was checked by ulan@chromium.org

[commit-bot: I haz the power, 2015-06-16 14:30:49]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1179153002/20001

[commit-bot: I haz the power, 2015-06-16 14:45:30]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-16 14:45:32]

Try jobs failed on following builders:
  v8_linux_chromium_gn_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_chromium_gn_rel/bu...)

[ulan, 2015-06-17 08:38:02]

The CQ bit was checked by ulan@chromium.org

[ulan, 2015-06-17 08:38:03]

The patchset sent to the CQ was uploaded after l-g-t-m from jochen@chromium.org,
rmcilroy@chromium.org
Link to the patchset: https://codereview.chromium.org/1179153002/#ps40001
(title: "Rebase")

[commit-bot: I haz the power, 2015-06-17 08:38:22]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1179153002/40001

[commit-bot: I haz the power, 2015-06-17 08:50:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-17 08:50:47]

Try jobs failed on following builders:
  v8_linux_chromium_gn_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_chromium_gn_rel/bu...)

[ulan, 2015-06-17 11:29:08]

The CQ bit was checked by ulan@chromium.org

[ulan, 2015-06-17 11:29:09]

The patchset sent to the CQ was uploaded after l-g-t-m from jochen@chromium.org,
rmcilroy@chromium.org
Link to the patchset: https://codereview.chromium.org/1179153002/#ps60001
(title: "Provide empty body to enable roll in Chromium.")

[commit-bot: I haz the power, 2015-06-17 11:29:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1179153002/60001

[commit-bot: I haz the power, 2015-06-17 12:09:39]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-06-17 12:09:51]

Patchset 4 (id:??) landed as
https://crrev.com/31e3177bb01fbe2b0a1e2a08dc82165ee6fbe692
Cr-Commit-Position: refs/heads/master@{#29084}