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

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


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

android-one

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

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

Hi hajimehoshi@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 : Hajime Hoshi
  Commit : 2c01263f421bdf2ce677049317d83c06bdac5c77
  Date   : Mon Aug 14 06:36:57 2017
  Subject: Revert "Fix a leak of a document that is held by AutofillAgent"

Bisect Details
  Configuration: android_one_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:chrome:all_processes:reported_by_os:system_memory:native_heap:proportional_resident_size_avg/load_tools/load_tools_dropbox
  Change       : 2.69% | 24548420.5714 -> 25209859.5556

Revision             Result                   N
chromium@494015      24548421 +- 1292059      14      good
chromium@494017      24559051 +- 976035       9       good
chromium@494018      25682037 +- 1031841      6       bad       <--
chromium@494020      25361867 +- 1094187      6       bad
chromium@494025      25607627 +- 1001833      6       bad
chromium@494034      25209860 +- 1706299      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-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=load.tools.dropbox 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/8970272749414372960


For feedback, file a bug with component Speed>Bisection

The revert is to fix another regression  crbug.com/753071 . As the original change doesn't affect the performance, I don't think this revert is the culprit of the regression.

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

I verified #4 on the graph, the original landing did not improve memory. Kicking off another bisect. In the meantime, cc-ing test owner Juan: the bisect in #3 looks pretty clear-cut, any idea what could be going on?

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

Suspected Commit
  Author : Hajime Hoshi
  Commit : 2c01263f421bdf2ce677049317d83c06bdac5c77
  Date   : Mon Aug 14 06:36:57 2017
  Subject: Revert "Fix a leak of a document that is held by AutofillAgent"

Bisect Details
  Configuration: android_one_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:chrome:all_processes:reported_by_os:system_memory:native_heap:proportional_resident_size_avg/load_tools/load_tools_dropbox
  Change       : 4.90% | 24479520.0 -> 25678965.3333

Revision             Result                   N
chromium@494015      24479520 +- 756662       6      good
chromium@494017      24502048 +- 738076       6      good
chromium@494018      25276704 +- 856669       6      bad       <--
chromium@494021      25530144 +- 752728       6      bad
chromium@494026      25541067 +- 1785405      9      bad
chromium@494036      25672821 +- 1268073      6      bad
chromium@494057      25651431 +- 1646561      9      bad
chromium@494099      25678965 +- 1253827      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-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=load.tools.dropbox 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/8969081268259957648


For feedback, file a bug with component Speed>Bisection

Bisect results have a bit of noise but they do look pretty solid.

Digging into other metrics, this appears to be related to some bi-modality in by_chrome:web_cache:effective_size on the renderer process (see attachment).

You can actually see being bi-modal for a long while, becoming stuck to the lower value when r492278 landed (the original CL) and then bi-modal again at the revert in r494018:
https://chromeperf.appspot.com/report?sid=9ad04afba5cada19438ab60f45eb054500e8e90078e30f618426c388fc9c4216&rev=494034

I assume you're planning to re-land. So I would suggest to run some tryjobs with any potential changes and look for clues in these metrics.

Deleted: native_heap_web_cache.png 29.9 KB

	native_heap_web_cache.png 29.9 KB View Download

Thank you for your investigating. We confirmed that our autofill-fix changed the web_cache behavior (resident size), that we expected but didn't know.

Yes, we plan to reland this fix after resource-cache management is fixed by hiroshige@.