yeah something definitely broken here

oh this one is fun.. root cause is this crash fix: https://codereview.chromium.org/1832423004

It gets into a live lock situation:
0. attach webview, load a page, how there is content in compositor, and frames in RT
1. detach webview, RT frames released back to compositor, memory set to 0
2. attach webview
3 draw
3.1 assign memory to compositor, compositor does *not* yet start raster work
3.2 compositor DrawAndSwap, which does not swap due to checkerboarding (no tiles). note this is wai since compositor assumes RT still has its frame; and swapping a checkerboarded frame looks bad. But since it checkerboarded, it will request a new frame
3.3 compositor PrepareTiles, which finally starts rastering tiles
3.4 BVR notices there is no frame from compositor or from RT, sets hardware_enabled_ to false,then proceeds to set compositor memory to 0
4 compositor throws away all work started in 3.3
5 since 3.2 requested another frame, everything repeats from 3 again


3.4 is the new thing added in the crash fix. Should be possible to avoid it.

Before M51 is released, app should be able to workaroudn this by not detaching webview between page loads.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7a7e615adc82dad9642eacf1002f681cd5fb584b

commit 7a7e615adc82dad9642eacf1002f681cd5fb584b
Author: boliu <boliu@chromium.org>
Date: Sat May 14 02:05:56 2016

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}

[modify] https://crrev.com/7a7e615adc82dad9642eacf1002f681cd5fb584b/android_webview/browser/browser_view_renderer.cc
[modify] https://crrev.com/7a7e615adc82dad9642eacf1002f681cd5fb584b/android_webview/browser/browser_view_renderer.h

Your change meets the bar and is auto-approved for M51 (branch: 2704)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5733e91f080449584a5567c41bd1a4ac5b08fa50

commit 5733e91f080449584a5567c41bd1a4ac5b08fa50
Author: Bo Liu <boliu@chromium.org>
Date: Sat May 14 14:27:40 2016

[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)

Review URL: https://codereview.chromium.org/1985483002 .

Cr-Commit-Position: refs/branch-heads/2704@{#550}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/5733e91f080449584a5567c41bd1a4ac5b08fa50/android_webview/browser/browser_view_renderer.cc
[modify] https://crrev.com/5733e91f080449584a5567c41bd1a4ac5b08fa50/android_webview/browser/browser_view_renderer.h

Verified the issue no longer reproducible on 5.X and 6.x Device with the latest build.

 Issue 614947  has been merged into this issue.