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

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


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

android-nexus9

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

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

Trying another bisect.

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

Hi tzik@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Make WebTraceLocation be an alias of tracked_objects::Location
Author  : tzik
Commit description:
  
Make WebTraceLocation be an alias of tracked_objects::Location and
BLINK_FROM_HERE be an alias of FROM_HERE as well. So that tasks posted
from Blink leaves a valid program counter and line number in the crash
dump.

Review-Url: https://codereview.chromium.org/2137013002
Cr-Commit-Position: refs/heads/master@{#405736}
Commit  : 3c109dd65c1984237444da93f7c7acc8b0bdcd92
Date    : Fri Jul 15 09:53:07 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@405726  2228224  0.0      5  good
chromium@405734  2228224  0.0      5  good
chromium@405735  2228224  0.0      5  good
chromium@405736  2359296  0.0      5  bad    <--
chromium@405738  2359296  0.0      5  bad
chromium@405741  2333082  58617.2  5  bad

Bisect job ran on: android_nexus9_perf_bisect
Bug ID: 629112

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests system_health.memory_mobile
Test Metric: load_search-memory:chrome:all_processes:reported_by_chrome:blink_gc:effective_size_avg/load_search_ebay
Relative Change: 4.71%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus9_perf_bisect/builds/1937
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9005788130568446096


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5815330568404992

| 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 Tests>AutoBisect.  Thank you!

Speculative revert in https://codereview.chromium.org/2218933003/

Revert does not come clean. tzik@, can you investigate this regression?

I think it's not related to my CL, since it's not a GCed object nor a member of GCed objects.
didn't it just touch the threshold of the allocation unit?

haraken: Do you have any idea to this?

petrcermak@: You should have a better sense at looking at memory regression on the system health plan :) Do you think this is a real regression? Or is it likely to be a noise?

I would not say that this is noise because the results had zero standard deviation (despite running 5 times):

Revision         Mean     Std Dev  N  Good?
chromium@405735  2228224  0.0      5  good
chromium@405736  2359296  0.0      5  bad

This seems to be a very clear +128 KiB regression in blink_gc on Ebay. I suggest you try running the benchmark locally against ToT (ChromePublic.apk) and with your patch reverted:

$ tools/perf/run_benchmark system_health.memory_mobile --browser=android-chromium --device=android --story-filter=load:search:ebay

 Issue 629097  has been merged into this issue.

I think that there's no doubt that this is NOT a noise since it's happening on multiple platforms and multiple pages (128 KiB on Linux on Tumblr in  issue 629097 ). To run the story on Linux:

$ tools/perf/run_benchmark system_health.memory_desktop --browser=release --device=desktop --story-filter=load:social:tumblr

tzik@: Would you mind taking a look at your CL again?

BTW, 128 KiB is the size of Oilpan's heap page. It may be possible that your CL happened to change object allocations on Oilpan's heap very slightly, and as a result Oilpan started failing at releasing one heap page that had been released before your CL. If that is the case, we can just mark the bug as WontFix. However, given the fact that the regression is happening on multiple platforms on multiple pages, I suspect something more serious is going on there.

OK, I successfully reproduced it on may machine.

My CL added 16 bytes to former WebTraceLocation, and that increases the size of blink::TimerBase.
On the tumblr benchmark (#12), there were ~914 instance of WebTraceLocation at the same time, and 913 of them are held by blink::TimerBase.

That gains the peak memory usage by 14kB, and due to it, the metric hits the 128kB boundary.
This should be getting away since most of timers are being replaced with the task cancellation + postDelayedTask().

tzik: Thanks for the analysis. Shall we mark this regression as WontFix then?

Yes, we should. Let me mark this as WontFix.