Enable spare RenderProcessHost to be preinitialized.

chrome/android/java/src/org/chromium/chrome/browser/WarmupManager.java

Index: chrome/android/java/src/org/chromium/chrome/browser/WarmupManager.java
diff --git a/chrome/android/java/src/org/chromium/chrome/browser/WarmupManager.java b/chrome/android/java/src/org/chromium/chrome/browser/WarmupManager.java
index 7c6ccb38bc737891664f5ace3b09ebee4922aeba..ab0bfccabc8f7b46487b628b59e457c72000ff1f 100644
--- a/chrome/android/java/src/org/chromium/chrome/browser/WarmupManager.java
+++ b/chrome/android/java/src/org/chromium/chrome/browser/WarmupManager.java
@@ -248,6 +248,25 @@ public final class WarmupManager {
         }
     }
 
+    /**
+     * Warms up a spare, empty RenderProcessHost that may be used for subsequent navigations.
+     *
+     * The spare RenderProcessHost will be used automatically in subsequent navigations.
+     * There is nothing further the WarmupManager needs to do to enable that use.
+     *
+     * This uses a different mechanism than createSpareWebContents, below, and is subject

[Charlie Reis, 2017/06/25 23:48:27]

What is createSpareWebContents used for?  Do you think this new spare RPH
approach could be sufficient for its needs in the long term?

I also notice that createSpareWebContents is a no-op on low-end devices.  Should
we be doing the same here?

[mattcary, 2017/06/26 14:45:05]

It's unclear. The spare WebContents is used to speed up a new custom tabs
navigation, and because it also initializes the web contents in addition to the
RPH saves about 40ms [1]. On the other hand, the spare WebContents is managed in
the android world for tabs, and so won't help for the service worker startup
latency problem that inspired this change. The spare WebContents is not very
complicated to implement, though, so perhaps the 40ms is worth it. It hasn't
been decided yet.

 
After some discussion we've changed when the spare RPH is created that covers
this case---not on low-end devices specifically, but we're consistent about when
we think it's okay to create a new process.

[Charlie Reis, 2017/06/26 21:22:49]

Ok.  Out of curiosity, what was the link you meant to include for [1]?
Sorry, I'm confused-- where's the change that you mention?  The code in this
file hasn't changed, and createSpareWebContents is still inconsistent with this
one in that it calls SysUtils.isLowEndDevice().

[mattcary, 2017/06/28 13:14:38]

Oops! 
https://docs.google.com/document/d/1rFx8QHHydnny4T2zdiR3JPELjZRpYReE2cS18EqhJ...
The check against MaxRendererProcessCount in render_proces_host_impl.cc.

It seems better to consolidate all the logic about when to create a spare
renderer or not in one place (RPHImpl) rather than have it split between android
and native code. That will make this a lot easier to reason about if it is used
in more contexts than just the omnibox.

[Charlie Reis, 2017/06/28 22:31:34]

Agreed-- that seems like a good plan.

(Just to follow up, will the isLowEndDevice() call below go away at some point
to be consistent with this?)

[mattcary, 2017/06/29 12:57:09]

I suspect so. Possibly createSpareWebContents will just go away. I've created
crbug.com/737890 to track this formally.

+     * to fewer restrictions.
+     *
+     * This must be called from the UI thread.
+     */
+    public void createSpareRenderProcessHost(Profile profile) {
+        ThreadUtils.assertOnUiThread();
+        // Spare WebContents should not be used with spare RenderProcessHosts, but if one
+        // has been created, destroy it in order not to consume too many processes.
+        destroySpareWebContents();
+        nativeWarmupSpareRenderer(profile);
+    }
+
     /**
      * Creates and initializes a spare WebContents, to be used in a subsequent navigation.
      *
@@ -314,4 +333,5 @@ public final class WarmupManager {
     }
 
     private static native void nativePreconnectUrlAndSubresources(Profile profile, String url);
+    private static native void nativeWarmupSpareRenderer(Profile profile);
 }