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

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


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

android-one

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

=== Auto-CCing suspected CL author klaasb@google.com ===

Hi klaasb@google.com, 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 : [interpreter] Inline FastCloneShallowArrayStub into bytecode handler
Author  : klaasb
Commit description:
  
The CreateArrayLiteral bytecode handler now directly inlines the FastCloneShallowArrayStub.

BUG= v8:4280 

Review-Url: https://codereview.chromium.org/2341743003
Cr-Commit-Position: refs/heads/master@{#39562}
Commit  : 5deb0bc15788e2d553a720ce53b1ab3401823779
Date    : Tue Sep 20 18:04:50 2016


===== TESTED REVISIONS =====
Revision                       Mean    Std Dev  N  Good?
chromium@420030                877643  3288.44  5  good
chromium@420034                877240  1744.94  5  good
chromium@420036                875950  1500.03  5  good
chromium@420036,v8@3b4cc88e9c  881049  3727.3   5  good
chromium@420036,v8@5deb0bc157  912987  709.508  5  bad    <--
chromium@420036,v8@377358516f  913044  2019.89  5  bad
chromium@420036,v8@8c87ae9b88  913720  3195.91  5  bad
chromium@420037                911520  1720.74  5  bad
chromium@420044                912854  1011.39  5  bad

Bisect job ran on: android_one_perf_bisect
Bug ID: 649240

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests memory.top_10_mobile_stress
Test Metric: memory:chrome:renderer_processes:reported_by_chrome:v8:heap:code_space:effective_size_avg/memory:chrome:renderer_processes:reported_by_chrome:v8:heap:code_space:effective_size_avg
Relative Change: 4.01%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_one_perf_bisect/builds/1631
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9000844553298171248


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

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

Would close this as won't fix (but can't?), since some change in code space is to be expected because of the stub port and inlining into the interpreter.
There seems to be some factor involved compared to the pure size of the stub and bytecode handler and what's reported on the benchmarks. It's unclear to me where that comes from, but it seems consistent with other stub changes.