Enable spare RenderProcessHost to be preinitialized.

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

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 package org.chromium.chrome.browser;
 
 import android.annotation.SuppressLint;
 import android.content.Context;
 import android.os.AsyncTask;
 import android.os.StrictMode;
@@ skipping 231 matching lines @@
                 // Note that if two requests come for the same URL with two
                 // different profiles, the last one will win.
                 mPendingPreconnectWithProfile.put(url, profile);
             } else {
                 nativePreconnectUrlAndSubresources(profile, url);
             }
         }
     }
 
     /**
+     * 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.
      *
      * This creates a renderer that is suitable for any navigation. It can be picked up by any tab.
      * Can be called multiple times, and must be called from the UI thread.
      * Note that this is a no-op on low-end devices.
      */
     public void createSpareWebContents() {
         ThreadUtils.assertOnUiThread();
         if (mSpareWebContents != null || SysUtils.isLowEndDevice()) return;
         mSpareWebContents = WebContentsFactory.createWebContentsWithWarmRenderer(false, false);
@@ skipping 45 matching lines @@
         mSpareWebContents = null;
         mObserver = null;
     }
 
     private static void recordWebContentsStatus(int status) {
         RecordHistogram.recordEnumeratedHistogram(
                 WEBCONTENTS_STATUS_HISTOGRAM, status, WEBCONTENTS_STATUS_COUNT);
     }
 
     private static native void nativePreconnectUrlAndSubresources(Profile profile, String url);
+    private static native void nativeWarmupSpareRenderer(Profile profile);
 }