[Merge M51] aw: Avoid livelock bouncing between zero and non-zero memory

[Merge M51] 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
Review-Url: https://codereview.chromium.org/1975273003
Cr-Commit-Position: refs/heads/master@{#393730}
(cherry picked from commit 7a7e615adc82dad9642eacf1002f681cd5fb584b)

Committed: https://chromium.googlesource.com/chromium/src/+/5733e91f080449584a5567c41bd1a4ac5b08fa50

[boliu, 2016-05-14 14:30:25]

Description was changed from

==========
[Merge M51] 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

Review-Url: https://codereview.chromium.org/1975273003
Cr-Commit-Position: refs/heads/master@{#393730}
(cherry picked from commit 7a7e615adc82dad9642eacf1002f681cd5fb584b)
==========

to

==========
[Merge M51] 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

Review-Url: https://codereview.chromium.org/1975273003
Cr-Commit-Position: refs/heads/master@{#393730}
(cherry picked from commit 7a7e615adc82dad9642eacf1002f681cd5fb584b)

Committed:
https://chromium.googlesource.com/chromium/src/+/5733e91f080449584a5567c41bd1...
==========

[boliu, 2016-05-14 14:30:27]

Committed patchset #1 (id:1) manually as
5733e91f080449584a5567c41bd1a4ac5b08fa50 (tree was closed).