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

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


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

android-one
chromium-rel-win10
chromium-rel-win7-gpu-nvidia

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12dec4ad240000

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

[Interpreter] Enable sharing of load / store named property feedback by mythria@chromium.org
https://chromium.googlesource.com/v8/v8/+/9461aa561986b93d228f603faf3745ab36cfd5dd
8.495e+06 → 9.544e+06 (+1.049e+06)

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/136d7c85240000

I looked at the traces and the code space increases ~10KB (there are two renderer processes and the code size increases by ~5KB in each). I think it is because of "Implement Array.p.sort in Torque" [1]

The allocated_object size in old space actually decreases by ~6-7 KB (from 1437KB - 1427KB). I am not entirely sure why the effective size increases though. It increases by almost ~1MB while the allocated object size has actually decreased. May be some kind of fragmentation or some other reason. 

[1] https://chromium-review.googlesource.com/c/v8/v8/+/1086827

📍 Found significant differences after each of 2 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/136d7c85240000

Reland "[array] Implement Array.p.sort in Torque" by szuend@google.com
https://chromium.googlesource.com/v8/v8/+/aff803454745935ba7843257fcf10dce41dc33b1
3.433e+06 → 3.79e+06 (+3.569e+05)

[Interpreter] Enable sharing of load / store named property feedback by mythria@chromium.org
https://chromium.googlesource.com/v8/v8/+/9461aa561986b93d228f603faf3745ab36cfd5dd
3.796e+06 → 3.768e+06 (-2.797e+04)

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

See https://chromeperf.appspot.com/report?sid=342d6214e53b41170b112f0a0cbc2633402d996bf0460ceffc318373ded8d996&start_rev=554671&end_rev=567914 for the code-space/old-space charts mentioned in #5.

It looks like we're allocating two addtl old space pages for some reason. A similar jump occured earlier (up at Point ID: 554370, down at Point ID: 555972) with no visible reason. The reason itself is unclear from the graphs (but I think it's unrelated to Array.p.sort).

Yes,  I think the increase in effective size is not related to Array.p.sort. It is also not directly related to sharing of feedback slots. I looked at the traces and the effective memory of the old space increases while the allocated object size in old space actually decreases.

Adding GC team for any insight. Could this be somehow related to memory fragmentation which pushes for allocation of additional pages or memory compaction unable to compact them?

On linux, somehow the effective size drops by ~0.5 MB when the allocated object size has increased. Graphs here: https://chromeperf.appspot.com/report?sid=28a81f6378b2ac6dcb68826c8f0d5fa134ea77f6a32c8bb2d2fec7cd6b7533a1&start_rev=563965&end_rev=564846


I think we can close this as won't fix since the allocated_object_size looks Ok.