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

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


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

android-nexus6

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

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

Hi mlippautz@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 : [heap] Introduce hard limit for external memory
Author  : mlippautz
Commit description:
  
We introduce, similar to regular heap, a hard and a soft limit for external memory.
- Upon reaching the hard limit we do a full GC. The hard limit is a a delta from
  the size of external memory at last GC.
- Upon reaching the soft limit we start incremental marking. Each further
  AdjustAmountOfExternalMemory will trigger a marking step. The step size depends
  on how far we are away from the hard limit. Further away means we have still
  some wiggle room and the step will be small. Being closer to the hard limit
  makes it more likely to trigger a full GC, so we increase the step size.

BUG=chromium:621829

Review-Url: https://codereview.chromium.org/2256853003
Cr-Commit-Position: refs/heads/master@{#39133}
Commit  : ce66eec800e7329b0967b0f8eec7db05b2b22218
Date    : Fri Sep 02 12:13:14 2016


===== TESTED REVISIONS =====
Revision                       Mean     Std Dev  N  Good?
chromium@416268                660.849  6.40682  5  good
chromium@416273                655.32   5.48576  5  good
chromium@416276                657.613  4.30316  5  good
chromium@416277                658.078  3.22709  5  good
chromium@416277,v8@a804e9b018  659.217  7.50596  5  good
chromium@416277,v8@883e0e7036  661.585  4.71885  5  good
chromium@416277,v8@ce66eec800  583.305  1.606    5  bad    <--
chromium@416277,v8@17e9e2f4c8  584.575  4.28517  5  bad
chromium@416278                584.057  3.56179  5  bad
chromium@416287                584.06   3.44608  5  bad

Bisect job ran on: android_nexus6_perf_bisect
Bug ID: 645579

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests blink_perf.bindings
Test Metric: typed-array-construct-from-same-type/typed-array-construct-from-same-type
Relative Change: 11.62%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus6_perf_bisect/builds/2551
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9001970989030597472


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

| 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!

Ulan, can you please judge this one some time and revert in case needed?

FYI: Kentaro, this is one example of a fast path I meant when talking about these limits. We still have pretty relaxed limits in place (we don't reduce the hard limit as suggested) but are already sometimes tanking a fast path.

(back to OOO)

I think this is an expected perf regression because we've decided not trigger an external GC earlier than before.

I think it's fine to mark this as WontFix.

 Issue 645578  has been merged into this issue.