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

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


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

Android Builder

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

=== BISECT JOB RESULTS ===
Bisect failed for unknown reasons

Please contact the team (see below) and report the error.


Bisect Details
  Configuration: android_nexus7_perf_bisect
  Benchmark    : resource_sizes
  Metric       : MonochromePublic.apk_Specifics/normalized apk size


To Run This Test
  src/build/android/resource_sizes.py --chromium-output-directory {CHROMIUM_OUTPUT_DIR} --chartjson {CHROMIUM_OUTPUT_DIR}/apks/MonochromePublic.apk

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8982965146760997072

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6145666415329280


| 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 Speed>Bisection.  Thank you!

Built this commit before/after locally and repro'ed the 20kb regression in libmonochrome.so. Running it through //tools/binary_size shows:

* 3kb growth in read-only merge strings
* 3.5kb growth in .text, mostly from an increase in symbol padding
* 1kb decrease in .strtab

The main growth turns out to be from relocation packing doing a much worse job. 
.rel.dyn goes from 349224 to 365608 (16kb).

I don't think this is actionable.