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

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


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

android-nexus7v2

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

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

Hi jkummerow@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : jkummerow
  Commit : 75ce09b53392eee23f3c0c6727463f9d9ef9c73f
  Date   : Fri Apr 21 17:31:29 2017
  Subject: Fix HashTable growth strategy to be 2x instead of 4x

Bisect Details
  Configuration: android_nexus7_perf_bisect
  Benchmark    : v8.runtimestats.browsing_mobile_classic
  Metric       : GC:duration_avg/browse_chrome/browse_chrome_omnibox
  Change       : 27.06% | 154.851833333 -> 196.747166667

Revision                           Result                  N
chromium@466429                    154.852 +- 9.73518      6       good
chromium@466476                    157.07 +- 13.034        6       good
chromium@466500                    157.536 +- 20.6071      6       good
chromium@466512                    159.296 +- 26.7765      14      good
chromium@466513                    156.789 +- 18.0724      6       good
chromium@466513,v8@75ce09b533      210.369 +- 19.1105      6       bad       <--
chromium@466513,v8@dddfcfd0a9      205.475 +- 23.556       6       bad
chromium@466514                    196.497 +- 141.424      21      bad
chromium@466515                    200.99 +- 61.3878       14      bad
chromium@466518                    207.812 +- 25.9703      6       bad
chromium@466523                    196.747 +- 34.9977      6       bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=browse.chrome.omnibox v8.runtimestats.browsing_mobile_classic

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

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


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

I don't see anything to be done here on the V8 side.

The point of the blamed CL was to save memory. Growing dictionaries in smaller steps does mean a bit more computational work, so a small perf hit is expected. In particular, for dictionaries that grow to large sizes and now take more steps until they get there, more backing stores are allocated and later discarded, leading to a bit more GC work.

While the difference in the "GC:duration_avg" metric looks big (and is unexpected), it is also only a 50ms regression on a benchmark with an overall runtime of 46 minutes (which has /not/ regressed at this revision, on the contrary, it's improved slightly, but that might just be noise).

The memory saving benefit has been achieved: https://chromeperf.appspot.com/group_report?rev=466514 shows up to 8% reduction in V8 memory consumption on mobile (memory:webview:all_processes:reported_by_chrome:v8:effective_size_avg/foreground/https_m_facebook_com_rihanna).

 Issue 714709  has been merged into this issue.

 Issue 715095  has been merged into this issue.