PlzNavigate: implement process reuse for ServiceWorkers

content/browser/site_instance_impl.h

Index: content/browser/site_instance_impl.h
diff --git a/content/browser/site_instance_impl.h b/content/browser/site_instance_impl.h
index 4898b17c0d3d9c3d450e051195ad8f3e901233a4..04484864d031c2db984f6e2d8d93d78248d5e55d 100644
--- a/content/browser/site_instance_impl.h
+++ b/content/browser/site_instance_impl.h
@@ -64,6 +64,12 @@ class CONTENT_EXPORT SiteInstanceImpl final : public SiteInstance,
     // In this mode, subframes will be hosted in a designated RenderProcessHost.
     USE_DEFAULT_SUBFRAME_PROCESS,
 
+    // In this mode, the site will be rendered in a suitable RenderProcessHost
+    // in priority, and a new RenderProcessHost will be created if none exist. A
+    // suitable RenderProcessHost is one that has a frame rendering the site, or
+    // that is expecting a navigation to the site.
+    REUSE_CHECKING_FRAMES_AND_NAVIGATIONS,

[Charlie Reis, 2017/05/15 03:41:52]

I'll suggest REUSE_PENDING_OR_COMMITTED_SITE.  That way "site" is in the name
(as the criteria for reuse), and pending vs committed seems like a more direct
comparison than "frames" vs "navigations" (which are independent concepts).

The comment can be slightly rephrased to convey this (and since "in priority"
wasn't explained):

In this mode, the site will be rendered in a RenderProcessHost that is already
in use for the site, either for a pending navigation or a committed navigation. 
If none exists, a new process will be created.  If multiple such processes
exist, ones that have foreground frames are given priority, and otherwise one is
selected randomly.

(As a side note, I think we might actually be able to use this exact behavior
for PROCESS_PER_SITE.  The main difference is using an existing process if a
navigation is pending, and I think that may actually fix a race in
process-per-site rather than cause problems.  That's for a followup CL, though,
and we should think it through.)

[clamy, 2017/05/16 14:50:46]

Done.

+
     // By default, a new RenderProcessHost will be created unless the process
     // limit has been reached. The RenderProcessHost reused will be chosen
     // randomly and not based on the site.