All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=676550

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg75qFsAoM


Bot(s) for this bug's original alert(s):

android-nexus5X

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8992600910010406944

Bisect failed: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5X_perf_bisect/builds/1014
Failure reason: the build has failed.

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8992466849357369296

=== PERF REGRESSION ===


=== Auto-CCing suspected CL author ulan@chromium.org ===

Hi ulan@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : [heap] Use RAIL mode for starting incremental marking.
Author  : ulan
Commit description:
  
This patch delays start of incremental marking during L phase of RAIL
and adjusts ShouldOptimizeForLoadTime to check allocation limit.

BUG= chromium:613518 

Review-Url: https://codereview.chromium.org/2583033003
Cr-Commit-Position: refs/heads/master@{#41797}
Commit  : 039e29f7505cf75d27d7681fab51d50f53dcc7bd
Date    : Mon Dec 19 11:34:34 2016


===== TESTED REVISIONS =====
Revision                       Mean      Std Dev   N   Good?
chromium@439571                0.631321  0.833947  30  good
chromium@439571,v8@81dd9847cf  0.638202  0.840894  30  good
chromium@439571,v8@58247e87be  0.622729  0.875178  30  good
chromium@439571,v8@039e29f750  0.799546  0.139924  30  bad    <--
chromium@439571,v8@52702e55aa  0.786711  0.277172  30  bad
chromium@439571,v8@8ac9e55aa6  0.796182  0.334474  30  bad
chromium@439572                0.794896  0.342458  30  bad
chromium@439573                0.791744  0.235545  30  bad
chromium@439574                0.793208  0.173399  25  bad
chromium@439577                0.786454  0.311961  30  bad
chromium@439583                0.800185  0.189164  30  bad
chromium@439595                0.797524  0.274681  30  bad
chromium@439618                0.803207  0.144336  30  bad
chromium@439664                0.798325  0.412708  30  bad

Bisect job ran on: win_8_perf_bisect
Bug ID: 676550

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests v8.infinite_scroll-ignition_tbmv2
Test Metric: v8-gc-incremental-step_avg/v8-gc-incremental-step_avg
Relative Change: 26.45%

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/win_8_perf_bisect/builds/2308
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8992466849357369296


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6138629217320960

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

This is expected. The story measures memory usage immediately after load and my CL postpones GC until after load to improve the load time.

If we would measure memory usage few seconds after the load there would be no regression.