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

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


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

android-webview-nexus6

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

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

Hi blundell@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 : blundell
  Commit : e75a8f91ce3a7a09d0da15f1c1fc83a79a668b8e
  Date   : Mon Mar 27 08:11:17 2017
  Subject: Device Service: Decouple Wake Lock from //content

Bisect Details
  Configuration: android_webview_nexus6_aosp_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:webview:all_processes:reported_by_chrome:malloc:effective_size_avg/load_search/load_search_google
  Change       : 1.03% | 22306935.4286 -> 22509928.0

Revision             Result                  N
chromium@459715      22306935 +- 513532      14      good
chromium@459717      22234622 +- 423521      9       good
chromium@459718      22414812 +- 269763      9       good
chromium@459719      22577383 +- 282965      9       bad       <--
chromium@459722      22551740 +- 310914      6       bad
chromium@459728      22459807 +- 414655      14      bad
chromium@459741      22509928 +- 323609      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=load.search.google system_health.memory_mobile

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

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


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

How can I see a version of this graph: https://chromeperf.appspot.com/group_report?bug_id=708673

that extends to ToT? I clicked around a bunch, but nothing jumped out at me as to how to extend the range to the right.

perezju: looks like the data stops for this chart on April 7, any ideas?

The benchmark recently moved from android-webview-nexus6 perf bot "2" to "1", and it looks like that bot is using the wrong browser. So it stopped reporting under "memory:webview" and now, mistakenly, reports under "memory:chrome".

So, sadly we don't seem to have data for ToT on for webview on nexus6. 

New data points are now flowing in, e.g.:
https://chromeperf.appspot.com/report?sid=000c75411b176e79a9056a75c1bc0f7d47fed188d7b168f6994ecb8a6bed01f8&start_rev=458942&end_rev=465514

Thanks! Nothing from my CL sticks out as problematic. Asked for more pairs of eyes on memory-dev@.

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

 I cross-checked the data on chromeperf [1] and that regressions seems to show up only on the webview N6 bot only on that page. No trace of that on the N5x, nor on the downstream webview bots, nor on clank (which at a first glance would make me suspect of a hw/os related flake).
Th repro from bisect bot is 163 KB, waterfall saw +400 K. However if you look at the output that the bisect pasted, 163 KB is really borderline with the noise coming from nearby CLs.
In other words, I'm not fully convinced about that bisect, although the jump on the chart linked from the bug is quite sharp. 
I rekicked another bisect here:
https://chromeperf.appspot.com/buildbucket_job_status/8981874447199070512

can't really tell how you could cause a regression only on one page only one bot. Let's see what the other bisect says

[1] https://chromeperf.appspot.com/report?sid=60c251c1c51a82361130aab5ef0dc4664fb5d62e4be8e3217144ed13a75aff4a&start_rev=458822&end_rev=460252

I checked two traces:

(before the peak) https://00e9e64bacaac333d9097540df5b5212a24fbab541e87f13a6-apidata.googleusercontent.com/download/storage/v1/b/chrome-telemetry-output/o/trace-file-id_27-2017-03-26_22-13-20-28898.html?qk=AD5uMEv35rXZ849pFuGkxQNEUrI7oxwOnqT0GAOgklfHl8Ys03lmtJpsJe6J10bZ_U1iiuoV9q55r3UEraEh1PscM6toizj_pfQqI_hDDV-Ce4F1C51Se3-0_F88uRUXmZD_6VhZ9GAPzFVw4qkF4HVqYgpGEEayG91c5iEyylHtuyBa1_tJRJ8fgv_TWuP2ovVHFauP-CasruDuNVpR-QOU7UO7Pmetxbsfe8s6ZWztLsjqmQtfWVY0WbxkS7DuhIiGiZuY_ARbCgTywB1yxVlA1SVFdcUe9D0V6FVUBtC2ilyj7JateOAY_HBwqwZ7J9kaqADS9rPrrAzeqidCT1kXnTiOjUjpjZhjBPz5EpQIBjyno7nj2bhqrFR6EGiyVKMV7kY26le2noQJ_3Uae2Cq5KQFAArIFdX-le32O01HLLptbJL6Sc7kixWv0r1Kdk0p69Dq3jzgs_C5I3m1EoxD_lmfHHeY0rJHNHBLGnPQPoOikau6u1WxBz8XAs4-_djRxRxVuqmIyDqwNW_xmnO75kS_H9sWz7RKMyi4KXZNFAKJyWfaX2Vas7yvmU9NjztxaLv1RwL9NU1gqc5W1e4QfMzacjiyBbZHaEd08eyAAXgqfSz7baBjyDVdu_pJxnSgRGYZWjEBZ5OjpqVqK5cgSOCw9a96O5iNupK6LSc3BLox9vV-RCZC3sk_We_9PbLtEmfihKleMppAX9efblgBy7J7W3WkOWMkeRN837LxFmT5mppKDlXfcs9r6pGSOSBn03dEMOATeBz0rPqo_emA1Gb3BGyscqh0BCT-yVvhRQsQVOYGYH59mH9eTQBhz2OUF9MlyZDLrxDmXxmmdaJNItjA3qVusA

(peak) https://00e9e64bacbe905c0b629ea385417e4c86b7e1cfd7990b243e-apidata.googleusercontent.com/download/storage/v1/b/chrome-telemetry-output/o/trace-file-id_27-2017-03-27_06-37-19-20279.html?qk=AD5uMEugtNTN6N9h20rvkA7r8yT_73YhggyQg6h7vrwrQbxxMMRtXlaMpPpcA5ZGaTWWUQv-09vp2bevrOBvM29vTzQLpyHnTIzimmw95TmbKPBrepmtJXL2s9zW_zRi2mzQYYM5sU9Mv4rb7-8MAf3H_HsRjd4W7Ys2Dox17IFteOzqUzwBi6J5Nw8RfJH1i6JPNIFIagzSBOdGFTNL9UIwDFDoDMNwpw0TaqDY5EALR1sEOYQgClRVNRgdWSugZ8PnKv9vbyxsLVpW9UZPDiHi5MtHi8davOhahiC37GxS_iFI5PQOpusOv4Aoa7ifNV-Cae9ZR5c-lbvb0DyVr2cNemlsIEaMHfptNGagDiI_UKWXLBg0WN2XiC1xzfbYQpLiVKj8zHZ8DalOQU1i5Kfynu8jxBm-Ie22_OkQrogt72Hyerni_9Yf1B8dZdjM2Oe_NI5UL11tU1gqmfq38m4Vgk7JRFZRZiHbT9sO7u7CfooxrsBJqmYg8ek1n875quWVDdi-aH6VQNBLgix4VnlW2E-Y51iTZFckvRxHSCUllqASFbtLSTSZwIonalUo8VcJkja57ypgjFjlKYesda0eKPgOofZdpiYT17o60_0DC9N6SbgpClPpsF1OezmSjTSONMv5J3cZWhMwVUqN4BB8-kCRqeNBUnLwkcscsCdN5aJQmWvALDQeHEMQIZMP4I1tcB--qJ3B_t-cmVpuqPPPjzAAhlrupmPkOeuG5Qgo1GjG5vjm3vojTwMUDvzd4_ANLbRm6eqItM55ELxxxNw8R2ZzQQQOcGvU5hqopG78MD0THjOFfzEAcfHIiruNIybXFw6oewr-iVFdiNlO5_BA8Tt1_enJxg

"malloc" is indeed .2KiB more on the peak, but I don't see it in "Memory Dumps / Native Heap":

* "Virtual Size" actually went down by 4 MiB
* "PSS" and "Private Dirty" stayed the same

Another interesting thing is that "cc" went down significantly: 21 MiB before the peak -> 18.9 MiB on the peak.

Given that:

1. I'm not convinced there is a regression. I suspect this might be related to Android (i.e. allocations are triggered by Java code). But since we share the same malloc, we can't say for sure.

2. We really, really, really need to separate Android allocations from Chrome's. primiano@, do we heave a bug for that?

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

Suspected Commit
  Author : blundell
  Commit : e75a8f91ce3a7a09d0da15f1c1fc83a79a668b8e
  Date   : Mon Mar 27 08:11:17 2017
  Subject: Device Service: Decouple Wake Lock from //content

Bisect Details
  Configuration: android_webview_nexus6_aosp_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:webview:all_processes:reported_by_chrome:malloc:allocated_objects_size_avg/load_search/load_search_google
  Change       : 0.40% | 54389118.2222 -> 54608531.5556

Revision             Result                  N
chromium@459715      54389118 +- 415289      9      good
chromium@459717      54446281 +- 382584      9      good
chromium@459718      54439635 +- 281143      6      good
chromium@459719      54705264 +- 213036      6      bad       <--
chromium@459722      54647487 +- 243922      9      bad
chromium@459728      54608509 +- 313381      9      bad
chromium@459741      54608532 +- 324238      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=load.search.google system_health.memory_mobile

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

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


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

Looking at https://chromeperf.appspot.com/report?sid=000c75411b176e79a9056a75c1bc0f7d47fed188d7b168f6994ecb8a6bed01f8&start_rev=443816&end_rev=467949, it looks like the jump at my CL is basically within the noise range of a bunch of subsequent drops and jumps that I see. I'm inclined to close this bug as WontFix. Anyone object?

WontFix-ing, agreed with #14 and previous comments.