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

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


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

android-webview-nexus6

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

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

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

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

Hi mek@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 : Marijn Kruisselbrink
  Commit : 5f2725f68003a78440a8c381b258bc338e910232
  Date   : Thu Jun 22 23:51:15 2017
  Subject: Change when leveldb wrappers are purged.

Bisect Details
  Configuration: android_webview_nexus6_aosp_perf_bisect
  Benchmark    : memory.top_10_mobile
  Metric       : memory:webview:all_processes:reported_by_os:system_memory:native_heap:proportional_resident_size_avg/background/after_http_yandex_ru_touchsearch_text_science
  Change       : 4.79% | 41791565.3333 -> 43794509.3333

Revision             Result                   N
chromium@481721      41791565 +- 1583198      6      good
chromium@481723      42013432 +- 415068       6      good
chromium@481724      42074872 +- 1187630      6      good
chromium@481725      43630669 +- 581330       6      bad       <--
chromium@481728      43535779 +- 692492       6      bad
chromium@481735      43787683 +- 342110       6      bad
chromium@481748      43794509 +- 911299       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 memory.top_10_mobile

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

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


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

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

Suspected Commit
  Author : Marijn Kruisselbrink
  Commit : 5f2725f68003a78440a8c381b258bc338e910232
  Date   : Thu Jun 22 23:51:15 2017
  Subject: Change when leveldb wrappers are purged.

Bisect Details
  Configuration: android_webview_nexus6_aosp_perf_bisect
  Benchmark    : memory.top_10_mobile
  Metric       : memory:webview:all_processes:reported_by_os:system_memory:native_heap:proportional_resident_size_avg/background/after_http_yandex_ru_touchsearch_text_science
  Change       : 5.14% | 41559117.3333 -> 43693986.6667

Revision             Result                   N
chromium@481721      41559117 +- 1171218      6      good
chromium@481723      41920077 +- 858506       6      good
chromium@481724      41757603 +- 576126       6      good
chromium@481725      43759181 +- 517655       6      bad       <--
chromium@481728      43739384 +- 721942       6      bad
chromium@481735      43527416 +- 1007572      6      bad
chromium@481748      43693987 +- 998051       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 memory.top_10_mobile

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

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


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

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

Suspected Commit
  Author : Marijn Kruisselbrink
  Commit : 5f2725f68003a78440a8c381b258bc338e910232
  Date   : Thu Jun 22 23:51:15 2017
  Subject: Change when leveldb wrappers are purged.

Bisect Details
  Configuration: android_webview_nexus6_aosp_perf_bisect
  Benchmark    : memory.top_10_mobile
  Metric       : memory:webview:all_processes:reported_by_os:system_memory:native_heap:proportional_resident_size_avg/background/after_http_www_baidu_com_s_word_google
  Change       : 1.64% | 35739270.2222 -> 36324543.1111

Revision             Result                  N
chromium@481721      35739270 +- 700015      9      good
chromium@481723      35660365 +- 849814      6      good
chromium@481724      35716401 +- 728016      9      good
chromium@481725      36281933 +- 570434      6      bad       <--
chromium@481728      36475128 +- 397068      6      bad
chromium@481735      36428365 +- 369669      6      bad
chromium@481748      36324543 +- 778794      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 memory.top_10_mobile

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

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


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

Since the purpose of the blamed CL was to increase how long certain instances are kept alive, it's only expected that that results in an increase in memory usage. On a comparison of the state after this CL with the state with the old localstorage implementation I didn't measure any meaningful increase in memory usage (the only measured increase I saw was mostly a timing thing, where with the new implementation memory dumps are taken at a time where some extra memory just happens to be allocated, while the old implementation allocated that same memory, but dumps just never included it). Not sure if reported_by_os:system_memory could be similarly effected, but either way I think this is pretty much expected. See also bug 730475 for some more discussion on memory usage of localstorage.

 Issue 736270  has been merged into this issue.

 Issue 736270  has been merged into this issue.

Issue 737340 has been merged into this issue.

Issue 737341 has been merged into this issue.

 Issue 736307  has been merged into this issue.