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

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


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

android-webview-nexus5X
android-webview-nexus6

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

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

Hi dgn@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 : Nicolas Dossou-gbete
  Commit : a1f36fd3560487bb6f2c2e4d140422780f700c32
  Date   : Mon Oct 30 12:57:10 2017
  Subject: 📱 Roll android support library to 27.0.0

Bisect Details
  Configuration: android_webview_arm64_aosp_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:webview:all_processes:reported_by_os:system_memory:java_heap:proportional_resident_size_avg/background_social/background_social_facebook
  Change       : 7.01% | 1518592.0 -> 1625088.0

Revision             Result                  N
chromium@512477      1518592 +- 0.0          6      good
chromium@512478      1528832 +- 0.0          6      good
chromium@512479      1635328 +- 0.0          6      bad       <--
chromium@512480      1629867 +- 9004.99      6      bad
chromium@512482      1625088 +- 0.0          6      bad
chromium@512486      1625088 +- 0.0          6      bad
chromium@512495      1625088 +- 0.0          6      bad
chromium@512512      1625088 +- 0.0          6      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.social.facebook 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/8964186888996955024


For feedback, file a bug with component Speed>Bisection

+primiano@ Could you have a look please?

 Issue 780236  has been merged into this issue.

Issue 782956 has been merged into this issue.

As per issue 782956 this also regressed webview startup time by 10ms..

benhenry@, we would like to roll the support library to 27.0.0 (see  issue 769683 ) but it triggered this regression. Could you please approve shipping with it still? 

Rationale for why we need this roll: https://docs.google.com/document/d/1xbDNBJPJ2-2DnJdITEpYXQqGXiiYHdDgZ5erSn7fQCU

Thanks!

Juan/Simon - this shows a java_heap regression of up to 6.9% in the lab. We're going to have to justify this to ship Android as it's over the threshold, but it looks like our justification is basically "Android is asking us to update our libraries to keep up with the latest SDK, those libraries have shown a java_heap regression." Does that sound correct and agreeable to you? 

For me, I feel like we should reach out to Android and ask what's really going on here.

The WebView startup time regression here is also blocking, per b/69005401

I started having a better look to find a cause to ask better questions to the Android team. As far as I can tell, here are the dependencies WebView has on the support library:
- annotations: from about everywhere, but is not supposed to impact runtime
- multidex: from //base
- v7_appcompat:
  - AppCompatResources from //components/autofill and //ui
- core_utils
  - unused dependency (since https://codereview.chromium.org/2627093009) from //components/variations

Did I miss anything?

I am surprised that the bots did not flag anything on Chrome itself, if we have so many WebView regressions. I'd suspect that maybe multidex of appcompat pulls in new things they didn't before and that we already used to load on Chrome anyway?

Re #12: From the alerts caught in this bug, the largest one is of ~220KiB, I don't think we need to worry too much about it. Even in relative terms on the health plan bots we're still under the 5% threshold for java heap, so there might not bee too much justification needed.

Not sure about the startup regression, though.

Re #14: On why this didn't flag an issue of Chrome, not sure if we have a corresponding equivalent for system_health.webview_startup, adding +pasko for that.

re startup regression: Chrome is too large and noisy to spot a <10ms startup regression, no surprise here

Issue 786331 has been merged into this issue.

This recovered.