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

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


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

android-nexus5

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

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

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

Hi epertoso@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 : [turbofan] Introduces the SpeculativeNumberShiftLeft opcode.
Author  : epertoso
Commit description:
  
Typed lowering now produces SpeculativeNumberShiftLeft for JSShiftLeft if the type feedback is kSignedSmall or kSigned32.

BUG= v8:4583 
LOG=n

Review-Url: https://codereview.chromium.org/2150553002
Cr-Commit-Position: refs/heads/master@{#37762}
Commit  : d93fd41aaa0982ae8c4226cce3f2629649ebe87a
Date    : Thu Jul 14 12:49:32 2016


===== TESTED REVISIONS =====
Revision                       Mean    Std Dev  N  Good?
chromium@405568                864904  1445.99  5  good
chromium@405570                862381  2913.01  5  good
chromium@405570,v8@95ba1af314  863808  2886.35  5  good
chromium@405570,v8@5abc73a1e8  864430  1123.0   5  good
chromium@405570,v8@d93fd41aaa  921218  3032.97  5  bad    <--
chromium@405570,v8@fee5858391  921549  1921.23  5  bad
chromium@405571                920690  2353.02  5  bad
chromium@405574                921549  1921.23  5  bad
chromium@405580                915454  16374.8  5  bad
chromium@405592                923992  1445.99  5  bad
chromium@405616                920995  2666.35  5  bad

Bisect job ran on: android_nexus5_perf_bisect
Bug ID: 628636

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_chrome:sqlite:effective_size_avg/load_tools_gmail
Relative Change: 6.49%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/3863
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9006395442005088112


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

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

Friendly perf-sheriff ping, could your patch have caused this memory regression?

I looked at it. My patch changes the (optimized) code that TurboFan emits when dealing with the '<<' operator in JavaScript. I don't think this might have caused the regression. The nexus-5 graph also went down again. Could it be some other CL in the same range?

epertoso: The bisect very clearly shows that the ~55 KiB regression was due to https://codereview.chromium.org/2150553002:

chromium@405570,v8@5abc73a1e8 (previous patch): 864,430 ± 1,123.00 B (good)
chromium@405570,v8@d93fd41aaa (your patch):     921,218 ± 3,032.97 B (bad)

With this CL we do allocate more IR nodes using the V8 zone allocator. Seems like this is unavoidable.