android: Limit num renderer to service slots

content/browser/renderer_host/render_process_host_unittest.cc

 // Copyright 2013 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.
 
 #include <stddef.h>
 
 #include <limits>
 #include <memory>
 #include <vector>
 
@@ skipping 52 matching lines @@
   EXPECT_TRUE(RenderProcessHostImpl::ShouldTryToUseExistingProcessHost(
         browser_context(), test_url));
 }
 #endif
 
 #if defined(OS_ANDROID)
 TEST_F(RenderProcessHostUnitTest, NoRendererProcessLimitOnAndroid) {
   // Disable any overrides.
   RenderProcessHostImpl::SetMaxRendererProcessCount(0);
 
-  // Verify that by default the limit on Android returns max size_t.

[Jay Civelli, 2017/04/03 16:19:48]

Should we add a TODO to bring that test back if/when we address this bug more
appropriately?

[boliu, 2017/04/03 16:33:03]

I think this is a really dumb check and should not exist period. Why does it
matter what that "infinite" constant is? The code below already shows creating
more renderers than practical is still allowed.

[Jay Civelli, 2017/04/03 16:40:50]

Makes sense.

-  EXPECT_EQ(std::numeric_limits<size_t>::max(),
-      RenderProcessHostImpl::GetMaxRendererProcessCount());
-
   // Add a few dummy process hosts.
   ASSERT_NE(0u, kMaxRendererProcessCount);
   std::vector<std::unique_ptr<MockRenderProcessHost>> hosts;
   for (size_t i = 0; i < kMaxRendererProcessCount; ++i) {
     hosts.push_back(base::MakeUnique<MockRenderProcessHost>(browser_context()));
   }
 
   // Verify that the renderer sharing still won't happen.
   GURL test_url("http://foo.com");
   EXPECT_FALSE(RenderProcessHostImpl::ShouldTryToUseExistingProcessHost(
         browser_context(), test_url));
 }
 #endif
 
 }  // namespace content