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

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


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

android-webview-nexus5X

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

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

Hi bmeurer@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 : bmeurer
  Commit : f0e3f8ea6f5b614259c6b5f1b87d64f31711f0bb
  Date   : Wed Mar 22 08:03:50 2017
  Subject: [ignition] Decrease code size multiplier to 24.

Bisect Details
  Configuration: android_webview_arm64_aosp_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:webview:all_processes:reported_by_chrome:v8:effective_size_avg/load_news/load_news_flipboard
  Change       : 4.71% | 11973733.3333 -> 12537426.6667

Revision                           Result                   N
chromium@458703                    11973733 +- 95502.6      6      good
chromium@458709                    12009952 +- 88621.1      6      good
chromium@458712                    11959737 +- 229352       6      good
chromium@458713                    11971556 +- 82736.4      6      good
chromium@458713,v8@01951c1598      11994363 +- 75133.1      6      good
chromium@458713,v8@07a43140d4      12023047 +- 111038       6      good
chromium@458713,v8@f0e3f8ea6f      12445576 +- 246406       6      bad       <--
chromium@458714                    12498521 +- 244751       6      bad
chromium@458724                    12537427 +- 95615.7      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=load.news.flipboard system_health.memory_mobile

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8984285791869299344

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6622311987281920


| 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 Speed>Bisection.  Thank you!

Ross, what is this measuring? Is this peak memory usage?
I'm not sure if we should just revert my CL for the code size multiplier again. Didn't seem to help immediately, even after Jaro's fix for resetting the ticks when ICs change. WDYT?

I think v8:effective_size_avg is measuring just the average size of the heap. I guess this is probably the additional optimized code which wouldn't otherwise be in the heap. +Hannes in case he has any comments.

Regarding reverting the code size multiplier, did it help anywhere? I noticed that it increased optimize time for runtime-callstats back to where it was before Jaro's fix but didn't notice any decrease in time spent JavaScript (although that bucket is more noisy).

Yes, it is average memory consumption over time. The regression comes from large object space: https://chromeperf.appspot.com/report?sid=97e46aa568a1f90246fc91447e0d129759d6937c5638b7376581b28260ca8eb6&start_rev=456330&end_rev=459733