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

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


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

android-nexus7v2

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

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

Hi watk@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 : Convert AVDAs thread hang detection to be timer based
Author  : watk
Commit description:
  
Previously AVDAManager counted the number of tasks pending on the construction
thread and considered the thread hung when that number exceeded a threshold.
Now we use a MessageLoop::TaskObserver to watch how long tasks take. If a task
takes longer than 800ms it's considered hung. This mechanism should be more
robust because we don't have to worry about counting the tasks correctly.

BUG= 638406 

Review-Url: https://codereview.chromium.org/2245333004
Cr-Commit-Position: refs/heads/master@{#413527}
Commit  : d8e0dfd15ced352e5a4128553397609fb08f4c00
Date    : Mon Aug 22 20:47:40 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N   Good?
chromium@413517  37327.8  299.267  21  good
chromium@413525  37334.0  267.581  18  good
chromium@413526  37123.2  163.521  5   good
chromium@413527  37603.6  145.618  18  bad    <--
chromium@413529  37584.0  126.996  18  bad
chromium@413533  37622.7  154.627  18  bad
chromium@413548  37550.7  102.174  18  bad

Bisect job ran on: android_nexus7_perf_bisect
Bug ID: 640499

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests webrtc.peerconnection
Test Metric: vm_private_dirty_final_renderer/vm_private_dirty_final_renderer
Relative Change: 0.13%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus7_perf_bisect/builds/3256
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9003463929572963936


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

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

oth@ can you try to reassign this. I looked at the changelist and didn't find an obvious candidate. I highly doubt this is related to my change which a) shouldn't affect memory, and b) doesn't change any renderer code (and this regression is renderer memory).

This is also causing failures of this test on the A1 android perf bots.
Return Code Bisect also pegs the same CL as the culprit.

https://bugs.chromium.org/p/chromium/issues/detail?id=640727

Hmm, alright, I'll investigate. 

Landed a fix for the failure mentioned #5. I'll keep an eye on this benchmark and see if it was caused by the same thing (seems unlikely but so does my change causing a renderer memory regression so I don't know..)

Tried running this benchmark with and without my change with logging relevant to my change and observed no difference. Also, this metric has come down again since this alert. So I don't think there's a real regression here.