Don't share renderers between unrelated tabs on Android.

content/browser/renderer_host/render_process_host_impl.cc

Index: content/browser/renderer_host/render_process_host_impl.cc
diff --git a/content/browser/renderer_host/render_process_host_impl.cc b/content/browser/renderer_host/render_process_host_impl.cc
index bca607235e007e0bfecf44112ccba7362c827381..4a70fe4b32c1d788ac351e1e5f9d746208a41d40 100644
--- a/content/browser/renderer_host/render_process_host_impl.cc
+++ b/content/browser/renderer_host/render_process_host_impl.cc
@@ -394,15 +394,23 @@ size_t RenderProcessHost::GetMaxRendererProcessCount() {
   if (g_max_renderer_count_override)
     return g_max_renderer_count_override;
 
-  // Defines the maximum number of renderer processes according to the
-  // amount of installed memory as reported by the OS. The calculation
-  // assumes that you want the renderers to use half of the installed
-  // RAM and assuming that each WebContents uses ~40MB.
-  // If you modify this assumption, you need to adjust the
-  // ThirtyFourTabs test to match the expected number of processes.
+  // On Android we don't maintain a limit on the number of renderer process
+  // hosts we keep around - we are happy with keeping a lot of these, as long as
+  // the number of live renderer processes remains reasonable, and on Android
+  // the OS takes care of that.
+#if defined(OS_ANDROID)

[klobag.chromium, 2014/06/27 16:25:42]

hmm, I don't think this is a good way. It makes this api very subtle.

[ppi, 2014/06/27 16:40:32]

But it doesn't diverge too much from the codepaths of the other platforms. We
still have all of the code working the same way, just returning infinity (-> no
limit) here (unless overriden) and a finite number on other platforms.

Alternative would be to make the change in
"ShouldTryToUseExistingProcessHost()", making it always return false on Android.
But this breaks the connection between GetMaxRendererProcessCount() and
ShouldTryToUseExistingProcessHos() and takes away the useful ability of
overriding the limit to have the old behavior back (e.g. for local
experimentation).

Wdyt?

[ppi, 2014/06/27 16:44:32]

Should we add a separate boolean function to the API like "bool
IsRendererProcessCountLimited()" to make this explicit / less tricky?

[jam, 2014/07/14 22:45:56]

I agree with Grace that it's confusing to return 0 to mean no limit. Why not
return SIZE_MAX?

[ppi, 2014/07/16 13:26:54]

Done.

+  return 0u;
+#endif
+
+  // On other platforms, we calculate the maximum number of renderer process
+  // hosts according to the amount of installed memory as reported by the OS.
+  // The calculation assumes that you want the renderers to use half of the
+  // installed RAM and assuming that each WebContents uses ~40MB.  If you modify
+  // this assumption, you need to adjust the ThirtyFourTabs test to match the
+  // expected number of processes.
   //
-  // With the given amounts of installed memory below on a 32-bit CPU,
-  // the maximum renderer count will roughly be as follows:
+  // With the given amounts of installed memory below on a 32-bit CPU, the
+  // maximum renderer count will roughly be as follows:
   //
   //   128 MB -> 3
   //   512 MB -> 6
@@ -1786,7 +1794,8 @@ bool RenderProcessHost::ShouldTryToUseExistingProcessHost(
   //       a renderer process for a browser context that has no existing
   //       renderers. This is OK in moderation, since the
   //       GetMaxRendererProcessCount() is conservative.
-  if (g_all_hosts.Get().size() >= GetMaxRendererProcessCount())
+  size_t render_host_limit = GetMaxRendererProcessCount();
+  if (render_host_limit && g_all_hosts.Get().size() >= render_host_limit)

[klobag.chromium, 2014/06/27 16:25:42]

Should we check the live process count?

[ppi, 2014/06/27 16:40:32]

Dead process hosts can come back (re-spawn their processes) without going
through this path. So for other platforms checking the number of process hosts
can make sense I think.

     return true;
 
   return GetContentClient()->browser()->