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

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

Hi fgorski@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 : Offline Page download bridge
Author  : fgorski
Commit description:
  
* This creates a stub of the bridge, which is not yet wired to the back-end.
* It also provides Java side tests for the bridge functionality.

BUG= 630817 

Review-Url: https://codereview.chromium.org/2171963002
Cr-Commit-Position: refs/heads/master@{#407916}
Commit  : 68cf753deab115193dac19ba10aacf454f4641f0
Date    : Tue Jul 26 21:21:19 2016


===== TESTED REVISIONS =====
Revision         Mean    Std Dev  N  Good?
chromium@407915  913408  0.0      5  good
chromium@407916  918323  1831.79  5  bad    <--
chromium@407917  918323  1831.79  5  bad
chromium@407918  917504  0.0      5  bad
chromium@407920  917504  0.0      5  bad

Bisect job ran on: android_nexus6_perf_bisect
Bug ID: 635854

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_tools-memory:chrome:all_processes:reported_by_os:system_memory:ashmem:private_dirty_size_avg/load_tools_stackoverflow
Relative Change: 0.45%
Score: 99.0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus6_perf_bisect/builds/2441
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9004807021815161152


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

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

Wow. This code does exactly nothing after that CL was landed, as we didn't wire it to the backend or front end. Is there a chance the tests are wrong?

fgorski: Yes, it's possible. I'll re-run the bisect (the regression is definitely r407916, r407917 or r407918).

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

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


===== SUSPECTED CL(s) =====
Subject : Offline Page download bridge
Author  : fgorski
Commit description:
  
* This creates a stub of the bridge, which is not yet wired to the back-end.
* It also provides Java side tests for the bridge functionality.

BUG= 630817 

Review-Url: https://codereview.chromium.org/2171963002
Cr-Commit-Position: refs/heads/master@{#407916}
Commit  : 68cf753deab115193dac19ba10aacf454f4641f0
Date    : Tue Jul 26 21:21:19 2016


===== TESTED REVISIONS =====
Revision         Mean    Std Dev  N  Good?
chromium@407915  913408  0.0      5  good
chromium@407916  917504  0.0      5  bad    <--
chromium@407917  917504  0.0      5  bad
chromium@407918  917504  0.0      5  bad

Bisect job ran on: android_nexus6_perf_bisect
Bug ID: 635854

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_tools-memory:chrome:all_processes:reported_by_os:system_memory:ashmem:private_dirty_size_avg/load_tools_stackoverflow
Relative Change: 0.45%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus6_perf_bisect/builds/2452
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9004720496909504032


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

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

fgorski: The second bisect confirmed that your patch (r407916) is responsible for the 4 KiB regression in ashmem (private dirty) on stackoverflow. Please investigate and decide whether any further action is necessary.

Bisect was incorrect. The object created in the patch is not instantiated.

Just looked at the suspected CL and it is indeed unclear how it could have regressed android memory during this test. It does a single thing, specifically registers the native methods of a new java class. This may have added a few bytes to some JNI table. Is it possible that as a result a 4K page is added to private dirty? If so, then it's hardly something that can be fixed or done differently... 

dimich: I agree. Thanks for the analysis!