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-platform.cc
File src/libplatform/default-platform.cc (right):
https://codereview.chromium.org/1179153002/diff/1/src/libplatform/default-platform.cc#newcode113
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.
https://codereview.chromium.org/1179153002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
