WIP - Control the lifetime of RenderThreadManager from Java.

Control the lifetime of RenderThreadManager from Java.

At the moment the lifetime of the RenderThreadManager instance stays
the same as it was previously, but we can now delay its destruction by
keeping the corresponding Java AwGLFunctor object alive, independently
of AwContents.

BUG=597167
Committed: https://crrev.com/53910e537e70af7b491ffaff4f581ea9c43fdb71
Cr-Commit-Position: refs/heads/master@{#386053}

[Tobias Sargeant, 2016-03-31 22:54:37]

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

[boliu, 2016-04-01 03:13:39]

You are cheating by not moving SRS to a_w/native, and instead messing with build
files. Not ok..

How about this:
SRS remains in a_w/browser. Factor out the SRSClient bits from AwC into a
separate class in a_w/native, and add a java SRS that completely owns it.

So eg requestDrawGL call would be SRS -> SRSClient (native) -> java SRS (->
AwContents? maybe) -> WebViewDelegate. I think if you do this correctly, there
should be no changes needed for the current SRS class.

We don't need a CleanupReference for java SRS because there is a clear point
when it should be completely destroyed. SRSClient does need to only keep weak
java ref to java SRS though, since presumably java SRS will keep a strong ref to
AwContents, and we can't have gc roots to AwContents.

Now is also a good time to rename SRS to something better. I hate that name.
hush and I originally thought it really will just be a state object, but clearly
it has grown past that. cc used to have "ThreadProxy", but SRS isn't really a
proxy either. Suggestions? cc hush too

https://codereview.chromium.org/1844343005/diff/1/android_webview/browser/sha...
File android_webview/browser/shared_renderer_state.cc (right):

https://codereview.chromium.org/1844343005/diff/1/android_webview/browser/sha...
android_webview/browser/shared_renderer_state.cc:154: DCHECK(client_);
How can you enforce this? This is not called by the client.

https://codereview.chromium.org/1844343005/diff/1/android_webview/java/src/or...
File
android_webview/java/src/org/chromium/android_webview/browser/SharedRendererState.java
(right):

https://codereview.chromium.org/1844343005/diff/1/android_webview/java/src/or...
android_webview/java/src/org/chromium/android_webview/browser/SharedRendererState.java:37:
mCleanupReference.cleanupNow();
There is no reason for a cleanupReference. This object should have an explicit
place to be destroyed, when AwContents is detached (or in that new callback in
N)

[boliu, 2016-04-01 03:15:21]

On 2016/04/01 03:13:39, boliu wrote:
> You are cheating by not moving SRS to a_w/native, and instead messing with
build
> files. Not ok..
> 
> How about this:
> SRS remains in a_w/browser. Factor out the SRSClient bits from AwC into a
> separate class in a_w/native, and add a java SRS that completely owns it.
> 
> So eg requestDrawGL call would be SRS -> SRSClient (native) -> java SRS (->
> AwContents? maybe) -> WebViewDelegate.

s/WebViewDelegate/NativeGLDelegate/

> I think if you do this correctly, there
> should be no changes needed for the current SRS class.
> 
> We don't need a CleanupReference for java SRS because there is a clear point
> when it should be completely destroyed. SRSClient does need to only keep weak
> java ref to java SRS though, since presumably java SRS will keep a strong ref
to
> AwContents, and we can't have gc roots to AwContents.
> 
> Now is also a good time to rename SRS to something better. I hate that name.
> hush and I originally thought it really will just be a state object, but
clearly
> it has grown past that. cc used to have "ThreadProxy", but SRS isn't really a
> proxy either. Suggestions? cc hush too
> 
>
https://codereview.chromium.org/1844343005/diff/1/android_webview/browser/sha...
> File android_webview/browser/shared_renderer_state.cc (right):
> 
>
https://codereview.chromium.org/1844343005/diff/1/android_webview/browser/sha...
> android_webview/browser/shared_renderer_state.cc:154: DCHECK(client_);
> How can you enforce this? This is not called by the client.
> 
>
https://codereview.chromium.org/1844343005/diff/1/android_webview/java/src/or...
> File
>
android_webview/java/src/org/chromium/android_webview/browser/SharedRendererState.java
> (right):
> 
>
https://codereview.chromium.org/1844343005/diff/1/android_webview/java/src/or...
>
android_webview/java/src/org/chromium/android_webview/browser/SharedRendererState.java:37:
> mCleanupReference.cleanupNow();
> There is no reason for a cleanupReference. This object should have an explicit
> place to be destroyed, when AwContents is detached (or in that new callback in
> N)

[boliu, 2016-04-01 05:54:01]

On 2016/04/01 03:15:21, boliu wrote:
> On 2016/04/01 03:13:39, boliu wrote:
> > You are cheating by not moving SRS to a_w/native, and instead messing with
> build
> > files. Not ok..
> > 
> > How about this:
> > SRS remains in a_w/browser. Factor out the SRSClient bits from AwC into a
> > separate class in a_w/native, and add a java SRS that completely owns it.
> > 
> > So eg requestDrawGL call would be SRS -> SRSClient (native) -> java SRS (->
> > AwContents? maybe) -> WebViewDelegate.
> 
> s/WebViewDelegate/NativeGLDelegate/
> 
> > I think if you do this correctly, there
> > should be no changes needed for the current SRS class.
> > 
> > We don't need a CleanupReference for java SRS because there is a clear point
> > when it should be completely destroyed. SRSClient does need to only keep
weak
> > java ref to java SRS though, since presumably java SRS will keep a strong
ref
> to
> > AwContents, and we can't have gc roots to AwContents.

I take back this CleanupReference bit for now. Let's keep the object lifetimes
roughly the same in this CL, ie keep SRSClient lifetime roughly the same
lifetime as native AwContents today, ie needing a CleanupReference to clean it
up.

Maybe one day in the future we can have SRSClient and HR have the same lifetime,
then the whole SRS chain of objects can be destroyed with an explicit signal
rather than gc.

> > 
> > Now is also a good time to rename SRS to something better. I hate that name.
> > hush and I originally thought it really will just be a state object, but
> clearly
> > it has grown past that. cc used to have "ThreadProxy", but SRS isn't really
a
> > proxy either. Suggestions? cc hush too
> > 
> >
>
https://codereview.chromium.org/1844343005/diff/1/android_webview/browser/sha...
> > File android_webview/browser/shared_renderer_state.cc (right):
> > 
> >
>
https://codereview.chromium.org/1844343005/diff/1/android_webview/browser/sha...
> > android_webview/browser/shared_renderer_state.cc:154: DCHECK(client_);
> > How can you enforce this? This is not called by the client.
> > 
> >
>
https://codereview.chromium.org/1844343005/diff/1/android_webview/java/src/or...
> > File
> >
>
android_webview/java/src/org/chromium/android_webview/browser/SharedRendererState.java
> > (right):
> > 
> >
>
https://codereview.chromium.org/1844343005/diff/1/android_webview/java/src/or...
> >
>
android_webview/java/src/org/chromium/android_webview/browser/SharedRendererState.java:37:
> > mCleanupReference.cleanupNow();
> > There is no reason for a cleanupReference. This object should have an
explicit
> > place to be destroyed, when AwContents is detached (or in that new callback
in
> > N)

[boliu, 2016-04-01 17:39:28]

kinda weird there are two SRSClient implementations, and the proxy one just pass
through calls to AwContents.

What if the proxy one had a pointer to BVR, then, it doesn't need to go through
native AwContents anymore. And in this CL (ie before lifetime changes), I think
it's possible to guarantee BVR outlives HR, so OnParentDrawConstraintsUpdated
can have a DCHECK maybe?

For the other methods, java SRSProxy can hold the NativeGLDelegate

https://codereview.chromium.org/1844343005/diff/20001/android_webview/BUILD.gn
File android_webview/BUILD.gn (right):

https://codereview.chromium.org/1844343005/diff/20001/android_webview/BUILD.g...
android_webview/BUILD.gn:655:
"java/src/org/chromium/android_webview/browser/SharedRendererStateProxy.java",
don't need the browser part, there isn't any android_webview java code on the
renderer side

https://codereview.chromium.org/1844343005/diff/20001/android_webview/java/sr...
File
android_webview/java/src/org/chromium/android_webview/browser/SharedRendererStateProxy.java
(right):

https://codereview.chromium.org/1844343005/diff/20001/android_webview/java/sr...
android_webview/java/src/org/chromium/android_webview/browser/SharedRendererStateProxy.java:13:
public class SharedRendererStateProxy {
don't need to be public?

[boliu, 2016-04-01 20:42:34]

Name.. I thought it should be RenderThread<blah>. Out of adapter, proxy, bridge,
manager, controller, delegate, owner, provider (and more I didn't write down), I
hate RenderThreadController the least. Certainly not settled, but in case we
don't have anything better..

[Tobias Sargeant, 2016-04-06 15:07:15]

Description was changed from

==========
WIP - Java obejct for SharedRendererState

BUG=597167
==========

to

==========
Control the lifetime of RenderThreadManager from Java.

At the moment the lifetime of the RenderThreadManager instance stays the same as
it was previously, but we can now delay its destruction by keeping the
corresponding Java AwGLFunctor object alive, independently of AwContents.

BUG=597167
==========

[boliu, 2016-04-06 16:09:01]

So there is AwGLFunctor.deleteHardwareRenderer and .destroy

deleteHardwareRenderer should still happen where they used to, in particular, I
think it no longer happens from AwContents.destroy

.destroy is less important, so you can do whatever is easiest for this CL

https://codereview.chromium.org/1844343005/diff/40001/android_webview/java/sr...
File android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java
(right):

https://codereview.chromium.org/1844343005/diff/40001/android_webview/java/sr...
android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java:42:
public void destroy() {
nothing calls this so far

https://codereview.chromium.org/1844343005/diff/40001/android_webview/native/...
File android_webview/native/android_webview_jni_registrar.cc (right):

https://codereview.chromium.org/1844343005/diff/40001/android_webview/native/...
android_webview/native/android_webview_jni_registrar.cc:67: {"AwGLFunctor",
RegisterAwGLFunctor},
can you not re-format here? Hard to review.

This used to be alphabetical, then MessagePortService broke the trend :/

[boliu, 2016-04-07 18:14:03]

https://codereview.chromium.org/1844343005/diff/100001/android_webview/BUILD.gn
File android_webview/BUILD.gn (right):

https://codereview.chromium.org/1844343005/diff/100001/android_webview/BUILD....
android_webview/BUILD.gn:666:
"java/src/org/chromium/android_webview/AwGLFunctor.java",
alphabetical

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
File android_webview/java/src/org/chromium/android_webview/AwContents.java
(right):

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwContents.java:7: import
static android.content.ComponentCallbacks2.TRIM_MEMORY_MODERATE;
Do you need this? Code that uses this is inside a ComponentCallbacks2 subclass.
And if that doesn't work, just do ComponentCallbacks2.TRIM_MEMORY_MODERATE
instead.

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwContents.java:1100:
nativeOnDetachedFromWindow(mNativeAwContents);
deleteHardwareRenderer first

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwContents.java:2708:
boolean requestDrawGL(boolean waitForCompletion) {
hmm, is it ok to set/unset mNativeGLDelegate + containerview instead of the
entire AwContents?

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
File android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java
(right):

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java:11: /**
Write some javadoc :)

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java:31:
public AwGLFunctor(AwContents.NativeGLDelegate nativeGLDelegate) {
remove arg

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java:32:
mAwContents = null;
redundant

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java:44:
mCleanupReference = null;
set mNativeAwGLFunctor to 0 here, then assert mNativeAwGLFunctor is not 0
everywhere its used

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java:64: if
(mAwContents != null) mAwContents.detachFunctorFromView();
the else case deserves a warning log, should never happen afaict..

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
File android_webview/native/aw_contents.cc (right):

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
android_webview/native/aw_contents.cc:294: if (functor_) {
SetAwGLFunctor(nullptr) instead to avoid spreading logic. So probably should
factor that out into a private helper method

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
android_webview/native/aw_contents.cc:315: if (functor != functor_) {
style: you can unindent the rest of the function if you do
if (functor == functor_)
  return;

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
File android_webview/native/aw_gl_functor.cc (right):

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
android_webview/native/aw_gl_functor.cc:69: delete this;
AwContents also has a java_ref_.reset() call here.

Also be consistent with thread checks. Add it to all public methods.

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
File android_webview/native/aw_gl_functor.h (right):

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
android_webview/native/aw_gl_functor.h:13: #include
"base/android/scoped_java_ref.h"
think this is only used in .cc file?

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
android_webview/native/aw_gl_functor.h:30: void SetClient(JNIEnv* env,
delete

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
android_webview/native/aw_gl_functor.h:35: 
nit: remove these blank lines between jni methods. it's not like you have
comments on them..

[boliu, 2016-04-07 18:28:27]

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
File android_webview/java/src/org/chromium/android_webview/AwContents.java
(right):

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwContents.java:1100:
nativeOnDetachedFromWindow(mNativeAwContents);
On 2016/04/07 18:14:03, boliu wrote:
> deleteHardwareRenderer first

this fixes the instrumentation test failure afaict

[Tobias Sargeant, 2016-04-07 21:07:36]

https://codereview.chromium.org/1844343005/diff/100001/android_webview/BUILD.gn
File android_webview/BUILD.gn (right):

https://codereview.chromium.org/1844343005/diff/100001/android_webview/BUILD....
android_webview/BUILD.gn:666:
"java/src/org/chromium/android_webview/AwGLFunctor.java",
On 2016/04/07 18:14:03, boliu wrote:
> alphabetical

Done.

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
File android_webview/java/src/org/chromium/android_webview/AwContents.java
(right):

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwContents.java:7: import
static android.content.ComponentCallbacks2.TRIM_MEMORY_MODERATE;
On 2016/04/07 18:14:03, boliu wrote:
> Do you need this? Code that uses this is inside a ComponentCallbacks2
subclass.
> And if that doesn't work, just do ComponentCallbacks2.TRIM_MEMORY_MODERATE
> instead.

Removed.

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwContents.java:1100:
nativeOnDetachedFromWindow(mNativeAwContents);
On 2016/04/07 18:14:03, boliu wrote:
> deleteHardwareRenderer first

would it be better to add onAttachedToWindow(AwContents /*for the moment */) and
onDetachedFromWindow() and deleteHardwareRenderer() in the latter?

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
File android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java
(right):

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java:31:
public AwGLFunctor(AwContents.NativeGLDelegate nativeGLDelegate) {
On 2016/04/07 18:14:03, boliu wrote:
> remove arg

Done.

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java:32:
mAwContents = null;
On 2016/04/07 18:14:03, boliu wrote:
> redundant

Done.

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java:44:
mCleanupReference = null;
On 2016/04/07 18:14:03, boliu wrote:
> set mNativeAwGLFunctor to 0 here, then assert mNativeAwGLFunctor is not 0
> everywhere its used

Done.

https://codereview.chromium.org/1844343005/diff/100001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java:64: if
(mAwContents != null) mAwContents.detachFunctorFromView();
On 2016/04/07 18:14:03, boliu wrote:
> the else case deserves a warning log, should never happen afaict..

Done.

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
File android_webview/native/aw_contents.cc (right):

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
android_webview/native/aw_contents.cc:294: if (functor_) {
On 2016/04/07 18:14:03, boliu wrote:
> SetAwGLFunctor(nullptr) instead to avoid spreading logic. So probably should
> factor that out into a private helper method

Done.

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
android_webview/native/aw_contents.cc:315: if (functor != functor_) {
On 2016/04/07 18:14:03, boliu wrote:
> style: you can unindent the rest of the function if you do
> if (functor == functor_)
>   return;

Done.

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
File android_webview/native/aw_gl_functor.cc (right):

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
android_webview/native/aw_gl_functor.cc:69: delete this;
On 2016/04/07 18:14:03, boliu wrote:
> AwContents also has a java_ref_.reset() call here.
> 
> Also be consistent with thread checks. Add it to all public methods.

Added.

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
File android_webview/native/aw_gl_functor.h (right):

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
android_webview/native/aw_gl_functor.h:13: #include
"base/android/scoped_java_ref.h"
On 2016/04/07 18:14:03, boliu wrote:
> think this is only used in .cc file?

Removed.

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
android_webview/native/aw_gl_functor.h:30: void SetClient(JNIEnv* env,
On 2016/04/07 18:14:03, boliu wrote:
> delete

Done.

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
android_webview/native/aw_gl_functor.h:35: 
On 2016/04/07 18:14:03, boliu wrote:
> nit: remove these blank lines between jni methods. it's not like you have
> comments on them..

Done.

[boliu, 2016-04-07 21:30:32]

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
File android_webview/native/aw_contents.cc (right):

https://codereview.chromium.org/1844343005/diff/100001/android_webview/native...
android_webview/native/aw_contents.cc:315: if (functor != functor_) {
On 2016/04/07 21:07:36, Tobias Sargeant wrote:
> On 2016/04/07 18:14:03, boliu wrote:
> > style: you can unindent the rest of the function if you do
> > if (functor == functor_)
> >   return;
> 
> Done.

No you didn't :p

https://codereview.chromium.org/1844343005/diff/140001/android_webview/java/s...
File android_webview/java/src/org/chromium/android_webview/AwContents.java
(right):

https://codereview.chromium.org/1844343005/diff/140001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwContents.java:875:
mAwGLFunctor.onAttachedToWindow(mNativeGLDelegate, mContainerView);
It's only safe to do this if view is correctly attached. Otherwise you are going
to have gc issues again.

Also maybe should just do this in awViewMethodsImpl.onAttachedToWindow since the
full screen flow is guaranteed to detach, then attach (if needed). I see that's
already there, so this line is totally redundant.

https://codereview.chromium.org/1844343005/diff/140001/android_webview/java/s...
File android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java
(right):

https://codereview.chromium.org/1844343005/diff/140001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java:91:
public void deleteHardwareRenderer() {
private

[Tobias Sargeant, 2016-04-07 21:39:49]

https://codereview.chromium.org/1844343005/diff/140001/android_webview/java/s...
File android_webview/java/src/org/chromium/android_webview/AwContents.java
(right):

https://codereview.chromium.org/1844343005/diff/140001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwContents.java:875:
mAwGLFunctor.onAttachedToWindow(mNativeGLDelegate, mContainerView);
On 2016/04/07 21:30:32, boliu wrote:
> It's only safe to do this if view is correctly attached. Otherwise you are
going
> to have gc issues again.
> 
> Also maybe should just do this in awViewMethodsImpl.onAttachedToWindow since
the
> full screen flow is guaranteed to detach, then attach (if needed). I see
that's
> already there, so this line is totally redundant.

Removed.

https://codereview.chromium.org/1844343005/diff/140001/android_webview/java/s...
File android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java
(right):

https://codereview.chromium.org/1844343005/diff/140001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java:91:
public void deleteHardwareRenderer() {
On 2016/04/07 21:30:32, boliu wrote:
> private

Done.

[boliu, 2016-04-07 21:43:33]

https://codereview.chromium.org/1844343005/diff/160001/android_webview/java/s...
File android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java
(right):

https://codereview.chromium.org/1844343005/diff/160001/android_webview/java/s...
android_webview/java/src/org/chromium/android_webview/AwGLFunctor.java:51:
deleteHardwareRenderer();
delete *before* setting the delegates to null

[Tobias Sargeant, 2016-04-07 21:43:38]

Patchset #9 (id:160001) has been deleted

[boliu, 2016-04-07 21:52:25]

lgtm

java doc

And wrap CL description at 72 chars

[Tobias Sargeant, 2016-04-08 11:49:51]

Description was changed from

==========
Control the lifetime of RenderThreadManager from Java.

At the moment the lifetime of the RenderThreadManager instance stays the same as
it was previously, but we can now delay its destruction by keeping the
corresponding Java AwGLFunctor object alive, independently of AwContents.

BUG=597167
==========

to

==========
Control the lifetime of RenderThreadManager from Java.

At the moment the lifetime of the RenderThreadManager instance stays
the same as it was previously, but we can now delay its destruction by
keeping the corresponding Java AwGLFunctor object alive, independently
of AwContents.

BUG=597167
==========

[Tobias Sargeant, 2016-04-08 11:59:19]

The CQ bit was checked by tobiasjs@chromium.org

[Tobias Sargeant, 2016-04-08 11:59:19]

The patchset sent to the CQ was uploaded after l-g-t-m from boliu@chromium.org
Link to the patchset: https://codereview.chromium.org/1844343005/#ps220001
(title: "Javadoc")

[commit-bot: I haz the power, 2016-04-08 11:59:32]

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

[commit-bot: I haz the power, 2016-04-08 12:34:42]

Description was changed from

==========
Control the lifetime of RenderThreadManager from Java.

At the moment the lifetime of the RenderThreadManager instance stays
the same as it was previously, but we can now delay its destruction by
keeping the corresponding Java AwGLFunctor object alive, independently
of AwContents.

BUG=597167
==========

to

==========
Control the lifetime of RenderThreadManager from Java.

At the moment the lifetime of the RenderThreadManager instance stays
the same as it was previously, but we can now delay its destruction by
keeping the corresponding Java AwGLFunctor object alive, independently
of AwContents.

BUG=597167
==========

[commit-bot: I haz the power, 2016-04-08 12:34:43]

Committed patchset #11 (id:220001)

[commit-bot: I haz the power, 2016-04-08 12:35:42]

Description was changed from

==========
Control the lifetime of RenderThreadManager from Java.

At the moment the lifetime of the RenderThreadManager instance stays
the same as it was previously, but we can now delay its destruction by
keeping the corresponding Java AwGLFunctor object alive, independently
of AwContents.

BUG=597167
==========

to

==========
Control the lifetime of RenderThreadManager from Java.

At the moment the lifetime of the RenderThreadManager instance stays
the same as it was previously, but we can now delay its destruction by
keeping the corresponding Java AwGLFunctor object alive, independently
of AwContents.

BUG=597167

Committed: https://crrev.com/53910e537e70af7b491ffaff4f581ea9c43fdb71
Cr-Commit-Position: refs/heads/master@{#386053}
==========

[commit-bot: I haz the power, 2016-04-08 12:35:43]

Patchset 11 (id:??) landed as
https://crrev.com/53910e537e70af7b491ffaff4f581ea9c43fdb71
Cr-Commit-Position: refs/heads/master@{#386053}