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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_9HHqQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg__Kh-wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDggLTkoAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_-v4rAkM


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

android-nexus5X

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

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

=== BISECT JOB RESULTS ===
NO Perf regression found

Bisect Details
  Configuration: android_nexus5X_perf_bisect
  Benchmark    : v8.mobile_infinite_scroll_tbmv2
  Metric       : memory:chrome:renderer_processes:reported_by_chrome:v8:heap:effective_size_max/memory:chrome:renderer_processes:reported_by_chrome:v8:heap:effective_size_max

Revision             Result                     N
chromium@441426      64114007 +- 124067553      30      good
chromium@441495      81947768 +- 217905319      30      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 v8.mobile_infinite_scroll_tbmv2

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

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


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

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

Hi dtapuska@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 : dtapuska
  Commit : 5494d50ab65532c64a28e91e23b0a722ebbfe8ed
  Date   : Wed Jan 04 22:02:35 2017
  Subject: Remove the requirement to only rAF align non-blocking touch moves.

Bisect Details
  Configuration: android_nexus5X_perf_bisect
  Benchmark    : v8.mobile_infinite_scroll_tbmv2
  Metric       : memory:chrome:renderer_processes:reported_by_chrome:v8:heap:allocated_objects_size_max/tumblr
  Change       : 110.04% | 48881991.1111 -> 102670001.778

Revision             Result                     N
chromium@441426      48881991 +- 21880054       9      good
chromium@441461      39533408 +- 16620165       6      good
chromium@441470      48944381 +- 17996904       6      good
chromium@441474      41624372 +- 13631964       6      good
chromium@441476      46454509 +- 18944174       6      good
chromium@441477      50267312 +- 14310997       6      good
chromium@441478      105627617 +- 35043297      6      bad       <--
chromium@441495      102670002 +- 73756665      9      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=tumblr v8.mobile_infinite_scroll_tbmv2

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

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


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

hablich@ see the regression on tumblr. The change I made is just actually causing a BeginMainFrame to be scheduled. Could the increase in the heap size be because we are continuously requesting begin main frames and this causes some heuristic in v8 GC not to kick in?

I'm trying to grab traces via https://codereview.chromium.org/2623833004 but I don't know if it will be successful

Could you post a --extra-browser-args="--js-flags=--trace-gc" output for both versions?

hapyer@ do you know how to do that with the bisect bot?
I might be able to run a try bot with a revert of my change I guess.

Some of the associated graphs are clear input latency regressions, which are almost definitely due to this change.

From the trybot (https://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5X_perf_bisect/builds/1075)


With change:
https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_0-2017-01-12_15-17-43-62737.html

Without change:
https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_0-2017-01-12_15-12-57-11751.html

The memory size seems almost the same to me in the two traces.

Err scratch that I was reading the memory traces wrong.

With the change I see the v8 memory size is 96.9MiB
Without the change I see the v8 memory size is 33.3MiB

Seems old_space has the bulk of the data. Can someone from the v8 team advise?

old_space is the old generation of the garbage collector. More objects are (for whatever reason alive). The "with" configuration seems to allocate more; it also triggers more full garbage collections.

If you search for "atomic pause" you will see 
usedHeapSizeBefore	
71666944
type	
"atomic pause"
usedHeapSizeAfter	
63860128
for the "with" configuration.

For the "without" configuration it is:
	
usedHeapSizeBefore	
33539344
type	
"atomic pause"
usedHeapSizeAfter	
30876804

Moreover, "with" has twice as many V8.execute events:
4128 vs. 8316

So there are:

With change there are 1998 ThreadProxy::BeginMainFrame
and without change there are 879 ThreadProxy::BeginMainFrame

And it appears each ThreadProxy::BeginMainFrame causes 3 V8::Executes

So this accounts for ~3357 of the extra V8.execute events.

I've reproduced this locally on a Nexus 5X and the page seems to infinitely scroll more content as opposed to in the case without the change it appears to cause overscroll glow and then all the events are sent to that and layout appears to be paused until the overscroll glow is dismissed.

The test page seems to be sensitive to event timing and this isn't a memory regression; just more content is loaded.

ulan@ it appears your test is working incorrectly for tumbler. The page wants to seem to cause the overscroll glow action on android. I don't think this is the desire of the test. How do you wish to proceed with this? There isn't a regression just some oddity because the test is sensitive to timing of events. 

I tried to set the parameters in the test to SCROLL_PAGE, 10, 30 like the discourse example and it seemed to allow the Nexus5X to be consistent between before my change and after my change. However when I tried on a Nexus 5 it still caused the overscroll glow.

I'd probably just mark this issue as WontFix and continue on.

Created  issue 682687  to deal with the actual issue with the test. The heap regression is expected due to increased dom nodes in the page.

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

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

Suspected Commit
  Author : schenney
  Commit : d3ba7664a7ebc6e74861602eb9696c7ca0a4ed2e
  Date   : Thu Jan 05 06:01:46 2017
  Subject: Fix border radius on composited children.

Bisect Details
  Configuration: android_nexus5X_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:chrome:all_processes:reported_by_chrome:cc:effective_size_avg/load_media/load_media_youtube
  Change       : 149.09% | 31646976.0 -> 78830632.0

Revision             Result                   N
chromium@441556      31646976 +- 431189       6      good
chromium@441579      31531736 +- 0.0          6      good
chromium@441591      31646949 +- 631049       6      good
chromium@441592      78945845 +- 862249       6      bad       <--
chromium@441593      78715392 +- 0.0          6      bad
chromium@441594      78830632 +- 631195       6      bad
chromium@441597      78907432 +- 1051846      6      bad
chromium@441602      78830632 +- 431189       6      bad

Please refer to the following doc on diagnosing memory regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md

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=load.media.youtube system_health.memory_mobile

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

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


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