Enable spare RenderProcessHost to be preinitialized.

content/public/browser/render_process_host.h

Index: content/public/browser/render_process_host.h
diff --git a/content/public/browser/render_process_host.h b/content/public/browser/render_process_host.h
index 778f93da8ceffbb9c6fa48d053c098f332289d64..67de6ffeadbcf0cd78a87cecda15c35be4e3e3a9 100644
--- a/content/public/browser/render_process_host.h
+++ b/content/public/browser/render_process_host.h
@@ -377,6 +377,23 @@ class CONTENT_EXPORT RenderProcessHost : public IPC::Sender,
 
   // Static management functions -----------------------------------------------
 
+  // Possibly start an unbound, spare RenderProcessHost. A subsequent call to
+  // CreateRenderProcessHost with a matching browser_context may use this

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

This comment makes it sound like any use of CreateRenderProcessHost will use the
spare if it's there.  (Relevant to our discussion of whether to include it there
or not.)

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

Rephrased, as CreateRenderProcessHost is not content/public but in
RenderProcessHostImpl (see reply to other comment).

+  // preinitialized RenderProcessHost, improving performance.
+  //
+  // It is safe to call this multiple times or when it is not certain that the
+  // spare renderer will be used, although calling this too eagerly may reduce
+  // performance as unnecessary RenderProcessHosts are created. The spare
+  // renderer may depend on details of the BrowserContext and will probably not
+  // be used if those details change (for example, the StoragePartition).

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

Let's rephrase this last bit to avoid "probably."  Something like:

The spare renderer will only be used if it has a matching BrowserContext and
StoragePartition.

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

OK, but my instinct is that those are implementation details that users of the
public interface should not rely on.

+  //
+  // The spare RenderProcessHost is meant to be created in a situation where a
+  // navigation is imminent and it is unlikely an existing RenderProcessHost
+  // will be used, for example in a cross-site navigation when a Service Worker
+  // will need to be started.
+  static void WarmupSpareRenderProcessHost(
+      content::BrowserContext* browser_context);
+
   // Flag to run the renderer in process.  This is primarily
   // for debugging purposes.  When running "in process", the
   // browser maintains a single RenderProcessHost which communicates