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

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


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

linux-perf
mac-10_13_laptop_high_end-perf

memory.long_running_idle_gmail_tbmv2 - Benchmark documentation link:
  None

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14b8cb03e40000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/116dc95ee40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/14b8cb03e40000

Start a field trial for Isolated code cache by mythria@chromium.org
https://chromium.googlesource.com/chromium/src/+/142ae7f8b7a7426ca426524a9593a39cc3e4f9ac
memory:chrome:renderer_processes:reported_by_chrome:v8:heap:allocated_objects_size: 6.129e+07 → 6.616e+07 (+4.871e+06)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  None

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16e3ff19e40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/116dc95ee40000

Start a field trial for Isolated code cache by mythria@chromium.org
https://chromium.googlesource.com/chromium/src/+/142ae7f8b7a7426ca426524a9593a39cc3e4f9ac
memory:chrome:renderer_processes:reported_by_chrome:v8:heap:allocated_objects_size: 6.149e+07 → 6.593e+07 (+4.443e+06)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  None

I am a bit surprised with this regression. The system_health loading stories run in cold mode, where there is no cache present and should not have much impact with the site-isolated code caches. I will take a look at the traces and see what is happening. 

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/16e3ff19e40000

Start a field trial for Isolated code cache by mythria@chromium.org
https://chromium.googlesource.com/chromium/src/+/142ae7f8b7a7426ca426524a9593a39cc3e4f9ac
memory:chrome:all_processes:reported_by_chrome:v8:effective_size: 9.218e+06 → 1.129e+07 (+2.071e+06)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  https://bit.ly/system-health-benchmarks

 Issue 900344  has been merged into this issue.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12938fbde40000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/13afc726e40000

📍 Job complete. See results below.
https://pinpoint-dot-chromeperf.appspot.com/job/12938fbde40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/13afc726e40000

[builtins] Port Array.p.join to Torque. by peter.wm.wong@gmail.com
https://chromium.googlesource.com/v8/v8/+/952c097679c5e16ae214595ad3b01381483eab7b
memory:chrome:renderer_processes:reported_by_chrome:v8:heap:allocated_objects_size: 6.493e+07 → 6.22e+07 (-2.726e+06)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  None

I can't reproduce these regressions reliably locally or using pinpoint jobs. I kind of feel it is a bit related to timing. The gmail long running benchmark had an improvement and after my cl it went back to the original value. I tried bisecting the improvement and it turned out to be Porting Array.p.join to Torque. I really don't think it could have caused a 18% improvement in allocated_object_size. This makes me believe it is a bit of timing thing and not an actual regression.

I am running a couple of more pinpoint jobs and local runs, but I still don't see how my CL could have caused this regression.

Issue 901953 has been merged into this issue.

I took a closer look at the traces for memory.long_running_idle_gmail_tbmv2, there is one additional render process (for contents.googleapis.com) which is about 15 MB of private footprint and about 2MB of V8 heap. That explains the regressions, but my cl shouldn't be impacting the number of render process at all. I am not sure why there is this additional render process in the 4-5 traces I checked after my change. Before my change this render process was not there. 

I tried this locally and with my patch there is always one additional render process corresponding to contents.googleapis.com. I tried to get the netlog and with my patch there is a request for contents.googleapis.com and without mine there is no request. It seems like a timing problem. I don't think the gmail regression is directly related to my change. 

I will have a look at others i.e. taobao and toi. 

For toi regression on FirstContentfull paint, I have a cl that optimizes the deferring logic. With the isolated code caches we have to wait for the response both from code cache and from the http cache. To implement this we defer the response from the URL loader. In the current implementation we defer more often than required. Deferring response has some amount of overhead. With the new cl, hopefully this should avoid deferring in most cases, and hence fix the regression. I will wait for it land and monitor the toi graph.

From comment #17, gmail looks more a timing issue and taobao recovered. Marking it as won't fix.