Schedule idle handler based on CPU usage.

Schedule idle handler based on CPU usage.

Previously, idle handler was scheduled only for inactive tabs and extensions
via a timer, regardless of CPU usage.

This CL enables idle handler for the active tab and unifies idle handler
scheduling for all three cases. By checking CPU usage and V8 feedback, the
new scheduling algorithm avoids redundant garbage collection requests.

BUG=
TEST=

[ulan, 2011-11-15 19:08:53]

Please take a look. Although this CL seems large, most of it is deleting code.

The main motivation is to enable V8 idle notifications on the active tab. This
helps to reduce memory usage when the user leaves a tab open for a long time.

This CL changes the idle handler scheduling algorithm and removes unused code,
including a few interface methods.

The old algorithm uses a timer in the render thread and works as follows:
- When WebKit is initialized and the current process is an extension process:
start the timer with 5 minute delay.
- On any extension activity: restart the timer with 5 second delay.
- When all widgets become hidden and the current process is not an extension
process: start the timer with 1 second delay.
- When a widget becomes visible and the current process is not an extension
process: stop the timer.
- When the timer fires: call V8::IdleNotification and restart the timer with
increased delay.

The new algorithm works is more uniform and works as follows:
- When WebKit is initialized: start the timer with the long delay (currently 30
seconds).
- On any extension activity: restart the timer with the short delay (currently 1
second).
- When all widgets become hidden: restart the timer with the short delay.
- When the timer fires: check the CPU usage since the last timer event. If the
CPU usage is low enough then call V8::IdleNotification and restart the timer
with either the long delay or the short delay depending on the result of the
function call. If the CPU usage is high then restart the timer with increased
delay.

http://codereview.chromium.org/8574012/diff/1/content/renderer/render_thread_...
File content/renderer/render_thread_impl.cc (right):

http://codereview.chromium.org/8574012/diff/1/content/renderer/render_thread_...
content/renderer/render_thread_impl.cc:105: static const int
kIdleCPUUsageThresholdInPercents = 3;
I have chosen these values based on GeneralMixMemoryTest but I am not sure that
these values are optimal. Any suggestions are welcome.

[Matt Perry, 2011-11-15 23:44:33]

In general this doesn't seem quite right to me. Previously the idle timer would
only run in cases where we thought the renderer was idle (like a background tab,
or an extension process that wasn't actually executing script recently). Now
we're guaranteed to run the idle timer every 30 seconds, even in foreground
tabs. Even if CPU usage is 0, I could be interacting with a foreground tab, and
notice a sudden hiccup as the idle timer fires and GC runs. Likewise for an
extension.

http://codereview.chromium.org/8574012/diff/1/chrome/renderer/extensions/exte...
File chrome/renderer/extensions/extension_dispatcher.cc (left):

http://codereview.chromium.org/8574012/diff/1/chrome/renderer/extensions/exte...
chrome/renderer/extensions/extension_dispatcher.cc:156:
kInitialExtensionIdleHandlerDelayMs);
The point of this code was to prevent the idle handler from running while an
extension was busy. It seems like your new ResetIdleTimer will not stop an
existing timer, it will only shorten the delay.

[ulan, 2011-11-16 14:16:50]

Thank you for the feedback! It made me realize that I shouldn't make many
changes at once. I'll try to split the changes to several CLs.

I uploaded the most important change http://codereview.chromium.org/8513008/.
The CL schedules the idle handler in the foreground tab and leaves the idle
handler scheduling for background tabs and extensions unchanged.

The CL also addresses your comment about user interaction, so idle notifications
are sent only when CPU usage is low and the user is not active. I hope that the
overhead of having an idle timer in the foreground tab is not a problem, because
we already have a running idle timer per background tab and per extension. The
frequency of these timers decrease with time, but in the first hour each of them
fires about 250 times (on average, every 14 seconds).

On 2011/11/15 23:44:33, Matt Perry wrote:
> In general this doesn't seem quite right to me. Previously the idle timer
would
> only run in cases where we thought the renderer was idle (like a background
tab,
> or an extension process that wasn't actually executing script recently). Now
> we're guaranteed to run the idle timer every 30 seconds, even in foreground
> tabs. Even if CPU usage is 0, I could be interacting with a foreground tab,
and
> notice a sudden hiccup as the idle timer fires and GC runs. Likewise for an
> extension.
> 
>
http://codereview.chromium.org/8574012/diff/1/chrome/renderer/extensions/exte...
> File chrome/renderer/extensions/extension_dispatcher.cc (left):
> 
>
http://codereview.chromium.org/8574012/diff/1/chrome/renderer/extensions/exte...
> chrome/renderer/extensions/extension_dispatcher.cc:156:
> kInitialExtensionIdleHandlerDelayMs);
> The point of this code was to prevent the idle handler from running while an
> extension was busy. It seems like your new ResetIdleTimer will not stop an
> existing timer, it will only shorten the delay.

[Aaron Boodman, 2011-11-23 22:52:20]

http://codereview.chromium.org/8574012/diff/1/chrome/renderer/extensions/exte...
File chrome/renderer/extensions/extension_dispatcher.cc (right):

http://codereview.chromium.org/8574012/diff/1/chrome/renderer/extensions/exte...
chrome/renderer/extensions/extension_dispatcher.cc:122: if
(is_extension_process_) {
Nit: the braces can go away now.