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
+     * to fewer restrictions.
+     *
+     * This must be called from the UI thread.
+     */
+    public void createSpareRenderProcessHost(Profile profile) {
+        ThreadUtils.assertOnUiThread();

[Ted C, 2017/06/30 16:16:56]

should we be excluding low end devices here?

i.e. 

if (SysUtils.isLowEndDevice()) return;

I thought we tried to limit the renderer count in that case to 0, and it would
be sad if that caused undo pressure on the visible tab.

[mattcary, 2017/07/03 08:03:02]

We manage the logic on when to create a spare renderer in
render_process_host_impl.cc rather than spread it across java and native code.
We restrict spare renderer creation according to the MaxRendererProcessCount
only. In the current usage, we create a spare renderer when we are almost
certain a new process will be created anyway, so it will not be adding pressure
that would not have been otherwise added.

[Ted C, 2017/07/05 03:54:05]

I looked at that as well, and I'm not seeing where low end devices are limited
through that code.

On Android, we don't limit it based on anything ram related:
https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_pro...

In fact, before this change https://codereview.chromium.org/2793623002, it was
unbounded.

Is there something I'm missing (again, this isn't the area I'm familiar with)? 
For low end devices, this functionality should be disabled (or at least that is
in line with all previous behavior on low end), so I don't think this is
something we want to rely on Android's killing logic to handle.  It is
definitely unfortunate to have this spread so many places, so I'd certainly like
to find a way to make that not required.

+        // 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);
 }