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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=662082ad611e6108355b658e4bd096842b5b1396a7ce0ccc490fef71a3573cff


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

health-plan-webview-low-end-phone

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

=== BISECT JOB RESULTS ===
Bisect was unable to run to completion

Error: INFRA_FAILURE

The bisect was able to narrow the range, you can try running with:
  good_revision: 45fa2bc178d5f5df6381ae274eaf6127932675b9
  bad_revision : 15c5456a8493381335ccc0fd80815f9ff77fa7cd

If failures persist contact the team (see below) and report the error.


Bisect Details
  Configuration: webview-low-end-phone-perf-bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:webview:all_processes:reported_by_chrome:v8:allocated_objects_size_avg/background_search/background_search_google
  Change       : 5.76% | 5928477.71429 -> 6270099.14286

Revision                                       Result                  N
android-chrome@3be694fa46                      5928478 +- 145345       14      good
android-chrome@79cd82244a                      5957017 +- 170349       14      good
android-chrome@79cd82244a,chromium@575459      5871411 +- 103.797      6       good
android-chrome@79cd82244a,chromium@575465      5871392 +- 137.516      14      good
android-chrome@79cd82244a,chromium@575466      5957101 +- 170411       14      good
android-chrome@79cd82244a,chromium@575467      6269667 +- 1134.43      14      bad
android-chrome@79cd82244a,chromium@575468      6269759 +- 1290.3       6       bad
android-chrome@79cd82244a,chromium@575471      6270316 +- 1476.51      9       bad
android-chrome@a84cb2f7c2                      6270099 +- 2806.66      14      bad

Please refer to the following doc on diagnosing memory regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=background.search.google system_health.memory_mobile

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8940665419677104928


For feedback, file a bug with component Speed>Bisection

Simon, this was marked as fixed in issue 698254. Any news on this?

This looks similar but it's actually just hitting the 24 hour global limit, I'll try restarting it. Typically it goes a lot faster on the 2nd run since all the builds were done by the first run and are cached.

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

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

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


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Frank Tang
  Commit : 02fe0c2477e1589a9d0df688f6f1be1322d0d306
  Date   : Mon Jul 16 18:37:25 2018
  Subject: [Intl] Plumb through locale and options from Array#toLocaleString

Bisect Details
  Configuration: webview-low-end-phone-perf-bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:webview:all_processes:reported_by_chrome:v8:allocated_objects_size_avg/background_search/background_search_google
  Change       : 5.98% | 5915792.0 -> 6269278.66667

Revision                                                     Result                  N
android-chrome@3be694fa46                                    5915792 +- 133335       9       good
android-chrome@79cd82244a                                    5928464 +- 145310       14      good
android-chrome@79cd82244a,chromium@575459                    5915803 +- 133405       9       good
android-chrome@79cd82244a,chromium@575465                    5928505 +- 145288       14      good
android-chrome@79cd82244a,chromium@575466                    5915775 +- 133343       9       good
android-chrome@79cd82244a,chromium@575466,v8@02fe0c2477      6272039 +- 4423.3       6       bad       <--
android-chrome@79cd82244a,chromium@575466,v8@66a2db59c1      6269139 +- 276.745      9       bad
android-chrome@79cd82244a,chromium@575467                    6270392 +- 1584.52      6       bad
android-chrome@79cd82244a,chromium@575468                    6269304 +- 826.838      9       bad
android-chrome@79cd82244a,chromium@575471                    6269762 +- 1364.82      9       bad
android-chrome@a84cb2f7c2                                    6269279 +- 449.319      9       bad

Please refer to the following doc on diagnosing memory regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=background.search.google system_health.memory_mobile

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8940559033048432208


For feedback, file a bug with component Speed>Bisection

 Issue 866393  has been merged into this issue.

Issue 867887 has been merged into this issue.

WiP https://chromium-review.googlesource.com/c/v8/v8/+/1245774

chat w/ gsathya
https://chromium.googlesource.com/v8/v8/+/02fe0c2477e1589a9d0df688f6f1be1322d0d306 does not change any c++ code but only js code and gsathya said it is impossible to cause system_health.memory_mobile issue

Issue 866080 has been merged into this issue.

You can look at the graphs by clicking on the link in #1. The regression is about V8 memory so no need to change C++ code to affect it.

Jakob and I looked at this. The bisection data does not seem to be flaky and does seem to correctly point to this CL as the culprit. But this CL doesn't seem to do anything wrong.

One hypothesis is that this CL makes use of the options and locales arguments that were previously just dropped immediately, potentially causing them to be moved to old space. This would make this as WAI.

I don't really have more insights here. mlippautz@, if you have any thoughts or ideas on how to proceed that'd be great. Otherwise, I'd suggest closing this out as WAI.

WAI sounds right here. Please don't just un-assign from bugs that clearly bisect and cause a regression as the bugs are likely never handled in this case.