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

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


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

chromium-rel-win7-gpu-ati
chromium-rel-win7-gpu-nvidia

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12b55a2f840000

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/12b55a2f840000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/128e629f840000

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/128e629f840000

📍 Pinpoint job started.
https://chromeperf.appspot.com/job/16d22c20440000

That's really weird, there clearly appears to be a regression according to the graph yet the bisect bot can't find it.

📍 Couldn't reproduce a difference.
https://chromeperf.appspot.com/job/16d22c20440000

The link in #8 should have been: https://pinpoint-dot-chromeperf.appspot.com/job/16d22c20440000 (CL to fix just landed).

+erikchen, any ideas why this wouldn't repro?

I think the metric "reported_by_chrome:malloc:effective_size_avg" is fundamentally flawed. For a longer discussion see https://bugs.chromium.org/p/chromium/issues/detail?id=736506. [That discusses v8 effective_size, but the same arguments apply].

I'm in the process of rolling out heap profiling, which will give us more accurate numbers:
https://chromium-review.googlesource.com/c/chromium/src/+/930041

And then we'll need to update the alerting to use shim_allocated_objects_size. If you think the CL in question may potentially cause problems, I'd recommend patching in the CL above and running locally to see if you get differences in shim_allocated_objects_size. 

Thanks, Erik! These regressions are small enough (and only on a few pages) that I think we can close this.