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

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


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

Android Nexus6 WebView Perf

memory.top_10_mobile - Benchmark documentation link:
  None

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/17820509e40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/17820509e40000

blink/bindings: Compress ParkableStrings in the background. by lizeb@chromium.org
https://chromium.googlesource.com/chromium/src/+/370d3c5b036bdc5e9cf1513a1316e6b128228fa6
memory:webview:all_processes:reported_by_os:system_memory:private_dirty_size: 2.598e+07 → 2.657e+07 (+5.853e+05)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  None

So, from an initial investigation:
- The pinpointed commit indeed can make memory measurements move
- However, it should only touch objects allocated with partition alloc, and graphs don't show any increase for partition alloc.

In essence, the commit above does:
- For some WTF::String, once the renderer has been backgrounded for 10s:
  1. One by one, GzipCompress() them on a background thread
  2. Puts the compressed output in a WTF::Vector on a background thread, and send it to the main thread
  3. On the main thread, frees the WTF::String, retain the WTF::Vector

In terms of memory footprint, the result should be a net decrease of memory usage, except perhaps between the end of (2) and (3) (as we then have both the compressed and uncompressed versions in RAM at the same time), but as this is done separately for each string, this shouldn't show up on the perf bots.

In terms of allocations, new ones are in (2):
- Temporary std::string (and std::vector in GzipCompress), allocated using malloc()
- long-lived WTF::Vector, using partition alloc

For instance, on this graph:
https://chromeperf.appspot.com/report?sid=2410136ffba14cde85614e0c03bd2677bfba8d22630935e867383f504d11bd8f&start_rev=601461&end_rev=605213

malloc()-ed data clearly increases, though partition alloc data decreases. Renderer private dirty does seem to increase a bit:
https://chromeperf.appspot.com/report?sid=3105b3beb15eeb39ed72eb614b894a04d314a1b137d85fd21f4d65aaa19ba645&start_rev=601461&end_rev=605213

Still investigating... Perhaps allocator fragmentation, though it is a bit of a stretch.

Issue 901962 has been merged into this issue.

 Issue 901966  has been merged into this issue.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14e8eae9e40000

📍 Found significant differences after each of 3 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/14e8eae9e40000

Update V8 to version 7.2.194. by v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/4acc35768905b732bdb87a335d7aa99f81b4c342
memory:webview:all_processes:reported_by_os:system_memory:private_dirty_size: 3.825e+07 → 3.695e+07 (-1.301e+06)

Rename blink::HTMLTokenizerNames namespace to blink::html_tokenizer_names by tkent@chromium.org
https://chromium.googlesource.com/chromium/src/+/2b8908b1271c50acfc28f59ab5b21ebcd2d3c5dd
memory:webview:all_processes:reported_by_os:system_memory:private_dirty_size: 3.694e+07 → 3.726e+07 (+3.24e+05)

Remove first_list_item_view_ in HoverListView by hongjunchoi@chromium.org
https://chromium.googlesource.com/chromium/src/+/0ac254b33b26cbc3164873a9dc160e127f49c476
memory:webview:all_processes:reported_by_os:system_memory:private_dirty_size: 3.726e+07 → 3.674e+07 (-5.226e+05)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  https://bit.ly/system-health-benchmarks