Add support for backgrounding processes on the Mac

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 1e20d8e6a899b551bc85a4362a7507ebdfb8bf39..9db94a14a517355c97b626d50900172c96826425 100644
--- a/content/browser/renderer_host/render_process_host_impl.cc
+++ b/content/browser/renderer_host/render_process_host_impl.cc
@@ -1,4 +1,4 @@
-// Copyright (c) 2012 The Chromium Authors. All rights reserved.
+// Copyright 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.
 
@@ -2252,6 +2252,12 @@ void RenderProcessHostImpl::SetBackgrounded(bool backgrounded) {
       base::FieldTrialList::Find("BackgroundRendererProcesses");
   if (!trial || trial->group_name() != "Disallow")
     child_process_launcher_->SetProcessBackgrounded(backgrounded);
+#elif defined(OS_MACOSX)
+  const std::string trial_group_name =

[gab, 2015/04/22 21:57:38]

Add a comment above similar to the Windows one (plus launch bug link).

[shrike, 2015/04/22 22:30:20]

Done.

+      base::FieldTrialList::FindFullName("BackgroundRendererProcesses");
+  if (trial_group_name.length() > 0 && trial_group_name != "Disallow") {

[gab, 2015/04/22 21:57:38]

s/trial_group_name.length() > 0/!trial_group_name.empty()

[shrike, 2015/04/22 22:30:20]

Done.

+    child_process_launcher_->SetProcessBackgrounded(backgrounded);
+  }

[gab, 2015/04/22 13:11:34]

Why not just re-use the Windows code for both?

As-is your experiment will not enabled by default on trunk (where there are no
experiments) and thus will not get perf waterfall coverage.

i.e. I'd say, just change the Windows ifdef to
#if defined(OS_WIN) || defined(OS_MACOSX)
instead of duplicating the code into a slightly different variant.

(one thing to be careful with enabling by default on trunk is that you'll to
create configs up to Stable right away to explicitly disable it there before it
gets approval)

[Alexei Svitkine (slow), 2015/04/23 20:53:28]

Agreed, no sense in having two slightly different but logically equivalent
codepaths right one after the other.

 #else
   // Control the background state from the browser process, otherwise the task
   // telling the renderer to "unbackground" itself may be preempted by other