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

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


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

android-webview-nexus6

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

=== BISECT JOB RESULTS ===
Perf regression found but unable to narrow commit range

Build failures prevented the bisect from narrowing the range further.


Bisect Details
  Configuration: android_webview_nexus6_aosp_perf_bisect
  Benchmark    : thread_times.simple_mobile_sites
  Metric       : thread_other_cpu_time_per_frame/http___m.nytimes.com_
  Change       : 3.93% | 2.27273547124 -> 2.34010147198

Suspected Commit Range
  3 commits in range
  https://chromium.googlesource.com/chromium/src/+log/a14fc27da0aabb9464e5d005d1775a22c5ffd36f..1278570bd438b22d1a703d67d441d813839d44ac


Revision             Result                    N
chromium@499530      2.27274 +- 0.279659       14       good
chromium@499534      2.24362 +- 0.0127196      6        good
chromium@499535      ---                       ---      build failure
chromium@499536      ---                       ---      build failure
chromium@499537      2.33265 +- 0.0200845      6        bad
chromium@499538      2.34357 +- 0.0403805      6        bad
chromium@499540      2.32676 +- 0.0761568      14       bad
chromium@499549      2.3401 +- 0.0554387       9        bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=http...m.nytimes.com. thread_times.simple_mobile_sites

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8969252579305565056


For feedback, file a bug with component Speed>Bisection

The only CL in the range that should affect the chrome binary is 'Revert "Do histogram validation after every JNI call."'. That's strange, because the original CL caused performance regressions across the board, but looking at the graphs, they all improved at the original CL. Assigning to bcwhite in case he wants to investigate further, but also WontFix-ing because it seems unlikely we want to reland the original CL.