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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDAv4S-vgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDA3-6zpQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDA39rkpQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDA36KKtwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDA36OYvwoM


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

android-nexus5
android-nexus9
android-one

kicked off bisect https://chromeperf.appspot.com/buildbucket_job_status/9018252277712185664

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

Hi keishi@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


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


===== SUSPECTED CL(s) =====
Subject : Fix and adjust PageNavigationGC threshold
Author  : keishi
Commit description:
  
We originally tried to estimate removal rate by counting the (nodes of the
detaching document) + (already deatached nodes).
Page navigation threshold was scheduled even when we were navigating from
about:blank because (already deatached nodes) count was inflated.
Nodes detached from JS is already accounted for in estimatedLiveSize through
collectedWrapperCount so we didn't need this.

Add estimatedRemovateRatio threshold of 1% because PageNavigationGC is for emergencies and normal situations should be handled by idle GC.

BUG=588029

Review URL: https://codereview.chromium.org/1763623002

Cr-Commit-Position: refs/heads/master@{#378973}
Commit  : f5ff205e2de07090a8dd52397b2573368fdc3229
Date    : Thu Mar 03 06:45:45 2016


===== TESTED REVISIONS =====
Revision                Mean Value  Std. Dev.   Num Values  Good?
chromium@378971         40672.5     232.409767  6           good
chromium@378972         40623.5     304.011748  8           good
chromium@378973         45692.6     427.595369  5           bad
chromium@378975         45868.6     237.447468  5           bad
chromium@378979         45744.4     238.374286  5           bad

Bisect job ran on: android_one_perf_bisect
Bug ID: 592010

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --also-run-disabled-tests page_cycler.basic_oopif
Test Metric: vm_private_dirty_final_renderer/vm_private_dirty_final_renderer
Relative Change: 12.35%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_one_perf_bisect/builds/1214
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9017932594219763488


| 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 label Cr-Tests-AutoBisect.  Thank you!

Ping keishi@. Can you look into whether your CL cause the regression and maybe revert it?

keishi@. gentle ping..

Ping keishi@ the third time.

Sorry for being to late to get back.

Previous discussion on crbug.com/588029, but my CL changes the lowers the frequency of BlinkGCs and so a regression in final memory size is expected. We should be looking at the peak size and even then we can only expect it to get bigger from this CL.

We know that basic_oopif reacted very badly to this change and saw >10% regression. But since other tests looked fine we decided to ignore it.