Enable spare RenderProcessHost to be preinitialized.

content/public/browser/render_process_host.h

 // Copyright (c) 2012 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.
 
 #ifndef CONTENT_PUBLIC_BROWSER_RENDER_PROCESS_HOST_H_
 #define CONTENT_PUBLIC_BROWSER_RENDER_PROCESS_HOST_H_
 
 #include <stddef.h>
 #include <stdint.h>
 
@@ skipping 359 matching lines @@
 
   // Posts |task|, if this RenderProcessHost is ready or when it becomes ready
   // (see RenderProcessHost::IsReady method).  The |task| might not run at all
   // (e.g. if |render_process_host| is destroyed before becoming ready).  This
   // function can only be called on the browser's UI thread (and the |task| will
   // be posted back on the UI thread).
   void PostTaskWhenProcessIsReady(base::OnceClosure task);
 
   // 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
   // to a RenderProcess which is instantiated in the same process
   // with the Browser.  All IPC between the Browser and the
   // Renderer is the same, it's just not crossing a process boundary.
 
   static bool run_renderer_in_process();
 
   // This also calls out to ContentBrowserClient::GetApplicationLocale and
@@ skipping 36 matching lines @@
   static void SetMaxRendererProcessCount(size_t count);
 
   // Returns the current maximum number of renderer process hosts kept by the
   // content module.
   static size_t GetMaxRendererProcessCount();
 };
 
 }  // namespace content.
 
 #endif  // CONTENT_PUBLIC_BROWSER_RENDER_PROCESS_HOST_H_