aw: Avoid livelock bouncing between zero and non-zero memory

aw: Avoid livelock bouncing between zero and non-zero memory

The assumption that compositor will produce a new frame immediately
after assigned memory is wrong. Which means resetting memory back to 0
if compositor does not produce a frame can cause a livelock. See bug for
a specific case where this actually happens.

Easy fix is just stop setting memory back to 0 at end of draw in this
case. This is safe because |hardware_enabled_| is only an internal state
of BrowserViewRenderer, and ReleaseHardware still guarantees memory set
back to 0 even if |hardware_enabled_| is false before the call. Remove
the getter to ensure nothing else can use |hardware_enabled_|.

Also revert unsetting |hardware_enabled_|, basically reverting the
original fix. This is no longer needed since RTM does not use this
condition to check whether it should clean up content on GL on render
thread.

BUG=611729
Committed: https://crrev.com/7a7e615adc82dad9642eacf1002f681cd5fb584b
Cr-Commit-Position: refs/heads/master@{#393730}

[boliu, 2016-05-13 23:15:25]

boliu@chromium.org changed reviewers:
+ hush@chromium.org

[boliu, 2016-05-13 23:15:25]

ptal

long term we should make memory policy depend on some other condition, but this
should be good enough for a quick fix

[hush (inactive), 2016-05-14 00:33:14]

lgtm % nit

https://codereview.chromium.org/1975273003/diff/1/android_webview/browser/bro...
File android_webview/browser/browser_view_renderer.cc (right):

https://codereview.chromium.org/1975273003/diff/1/android_webview/browser/bro...
android_webview/browser/browser_view_renderer.cc:247: hardware_enabled_ =
compositor_frame_consumer_->HasFrameOnUI();
just return compositor_frame_consumer_->HasFrameOnUI(); here. No need to assign
hardware_enabled.

[boliu, 2016-05-14 00:36:14]

Description was changed from

==========
aw: Avoid livelock bouncing between zero and non-zero memory

The assumption that compositor will produce a new frame immediately
after assigned memory is wrong. Which means resetting memory back to 0
if compositor does not produce a frame can cause a livelock. See bug for
a specific case where this actually happens.

Easy fix is just stop setting memory back to 0 at end of draw in this
case. This is safe because |hardware_enabled_| is only an internal state
of BrowserViewRenderer, and ReleaseHardware still guarantees memory set
back to 0 even if |hardware_enabled_| is false before the call. Remove
the getter to ensure nothing else can use |hardware_enabled_|.

BUG=611729
==========

to

==========
aw: Avoid livelock bouncing between zero and non-zero memory

The assumption that compositor will produce a new frame immediately
after assigned memory is wrong. Which means resetting memory back to 0
if compositor does not produce a frame can cause a livelock. See bug for
a specific case where this actually happens.

Easy fix is just stop setting memory back to 0 at end of draw in this
case. This is safe because |hardware_enabled_| is only an internal state
of BrowserViewRenderer, and ReleaseHardware still guarantees memory set
back to 0 even if |hardware_enabled_| is false before the call. Remove
the getter to ensure nothing else can use |hardware_enabled_|.

Also revert unsetting |hardware_enabled_|, basically reverting the
original fix. This is no longer needed since RTM does not use this
condition to check whether it should clean up content on GL on render
thread.

BUG=611729
==========

[boliu, 2016-05-14 00:36:45]

The CQ bit was checked by boliu@chromium.org

[boliu, 2016-05-14 00:36:48]

The patchset sent to the CQ was uploaded after l-g-t-m from hush@chromium.org
Link to the patchset: https://codereview.chromium.org/1975273003/#ps20001
(title: "revert fix")

[commit-bot: I haz the power, 2016-05-14 00:40:32]

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

[commit-bot: I haz the power, 2016-05-14 02:06:05]

Description was changed from

==========
aw: Avoid livelock bouncing between zero and non-zero memory

The assumption that compositor will produce a new frame immediately
after assigned memory is wrong. Which means resetting memory back to 0
if compositor does not produce a frame can cause a livelock. See bug for
a specific case where this actually happens.

Easy fix is just stop setting memory back to 0 at end of draw in this
case. This is safe because |hardware_enabled_| is only an internal state
of BrowserViewRenderer, and ReleaseHardware still guarantees memory set
back to 0 even if |hardware_enabled_| is false before the call. Remove
the getter to ensure nothing else can use |hardware_enabled_|.

Also revert unsetting |hardware_enabled_|, basically reverting the
original fix. This is no longer needed since RTM does not use this
condition to check whether it should clean up content on GL on render
thread.

BUG=611729
==========

to

==========
aw: Avoid livelock bouncing between zero and non-zero memory

The assumption that compositor will produce a new frame immediately
after assigned memory is wrong. Which means resetting memory back to 0
if compositor does not produce a frame can cause a livelock. See bug for
a specific case where this actually happens.

Easy fix is just stop setting memory back to 0 at end of draw in this
case. This is safe because |hardware_enabled_| is only an internal state
of BrowserViewRenderer, and ReleaseHardware still guarantees memory set
back to 0 even if |hardware_enabled_| is false before the call. Remove
the getter to ensure nothing else can use |hardware_enabled_|.

Also revert unsetting |hardware_enabled_|, basically reverting the
original fix. This is no longer needed since RTM does not use this
condition to check whether it should clean up content on GL on render
thread.

BUG=611729
==========

[commit-bot: I haz the power, 2016-05-14 02:06:06]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-05-14 02:07:24]

Description was changed from

==========
aw: Avoid livelock bouncing between zero and non-zero memory

The assumption that compositor will produce a new frame immediately
after assigned memory is wrong. Which means resetting memory back to 0
if compositor does not produce a frame can cause a livelock. See bug for
a specific case where this actually happens.

Easy fix is just stop setting memory back to 0 at end of draw in this
case. This is safe because |hardware_enabled_| is only an internal state
of BrowserViewRenderer, and ReleaseHardware still guarantees memory set
back to 0 even if |hardware_enabled_| is false before the call. Remove
the getter to ensure nothing else can use |hardware_enabled_|.

Also revert unsetting |hardware_enabled_|, basically reverting the
original fix. This is no longer needed since RTM does not use this
condition to check whether it should clean up content on GL on render
thread.

BUG=611729
==========

to

==========
aw: Avoid livelock bouncing between zero and non-zero memory

The assumption that compositor will produce a new frame immediately
after assigned memory is wrong. Which means resetting memory back to 0
if compositor does not produce a frame can cause a livelock. See bug for
a specific case where this actually happens.

Easy fix is just stop setting memory back to 0 at end of draw in this
case. This is safe because |hardware_enabled_| is only an internal state
of BrowserViewRenderer, and ReleaseHardware still guarantees memory set
back to 0 even if |hardware_enabled_| is false before the call. Remove
the getter to ensure nothing else can use |hardware_enabled_|.

Also revert unsetting |hardware_enabled_|, basically reverting the
original fix. This is no longer needed since RTM does not use this
condition to check whether it should clean up content on GL on render
thread.

BUG=611729

Committed: https://crrev.com/7a7e615adc82dad9642eacf1002f681cd5fb584b
Cr-Commit-Position: refs/heads/master@{#393730}
==========

[commit-bot: I haz the power, 2016-05-14 02:07:25]

Patchset 2 (id:??) landed as
https://crrev.com/7a7e615adc82dad9642eacf1002f681cd5fb584b
Cr-Commit-Position: refs/heads/master@{#393730}