commit 2b26997337e61e94757e0ad17901e94fccb0d1e3
author Lukasz Anforowicz <lukasza@chromium.org> Thu Apr 12 18:49:10 2018
committer Commit Bot <commit-bot@chromium.org> Thu Apr 12 18:49:10 2018
tree a1014e974b91d302e7321298e6d62708f14c7d62
parent be8dfba3407f0620676bcf566bc74208169324f6

Always keep a spare RenderProcessHost in presence of site-per-process.

This CL adds a feature for always keeping a separate RenderProcessHost
for the most recently used BrowserContext.  The feature is enabled by
default, but only consulted in presence of site-per-process.  Having a
spare renderer should hopefully avoid regressing page load metrics in
cross-site navigations (which before this CL needed to wait in
site-per-process mode until a new process was spawned).

After this CL, MaybeTakeSpareRenderProcessHost won't discard a
mismatched spare when in site-per-process mode (unless over the process
limit).  SpareRenderProcessHostManager::PrepareForFutureRequests method
has also been added - this method is responsible for warming-up another
spare in site-per-process mode.  PrepareForFutureRequests is called
when:
1. The previous spare was taken
   (in RenderProcessHostImpl::GetProcessHostForSiteInstance)
   Note: A new spare is not warmed-up when the previous spare was
         mismatched and not taken to avoid spawning two processes at the
         same time.
2. A navigation redirects into a SiteInstance that needs a new process
   (in NavigationRequest::OnRequestRedirected)
3. A navigation is ready to commit (this handles postponing spawning
   of the spare in the scenario handled in the note of scenario #1
   above;  this happens in NavigationRequest::CommitNavigation)
4. A same-site navigation happens (this retains the behavior from before
   the CL that allows discarding of the spare in this scenario;  this
   happens in RenderFrameHostManager::GetSiteInstanceForNavigation)

This CL also ensures that the spare is considered (and potentially
discarded) before considering process reuse because of the process
limit.  The change of the order of operations helps avoid process reuse
in some scenarios.

Remaining changes in this CL update various tests, so they can properly
account for the extra spare renderer.

Bug: 808114
Change-Id: Ica0226c2dc390102789b2c33f6b538c3e27eea82
Tbr: sky@chromium.org, sadrul@chromium.org, pavely@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/963405
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Vasilii Sukhanov <vasilii@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Albert J. Wong <ajwong@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550287}