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

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


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

android-nexus5X

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

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

[ignition] Set correct expression position for ObjectLiteral keys/values by gsathya@chromium.org
https://chromium.googlesource.com/v8/v8/+/acae2f2b65c94e80e26d3135bd3d94c02e689250

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

This is just from storing extra metadata  in the bytecode for the devtools. I don't think there's anything actionable here.

mythi, what do you think we should do here?

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

That's a large regression. It is only on yandex on Nexus5X. Since this is on v8:effective_size and not on v8:allocated_object_size, I think adding extra metadata caused allocation of a new page. If this is the case, I think we can ignore this regression. mlippautz@ does this explanation seem reasonable?

On v8:allocated_object_size there is a slight regression (~0.2-0.4% or 10-15KB)  across several pages around this range: I just started a bisect to be sure they are because of adding additional metadata.
 
https://chromeperf.appspot.com/report?sid=b14edabf2d66544bedac0721266d058ab68de4f37f25179fa7fe353cb0d1a553

Yep, the effective size regression looks like one page and you can see it as fyi.

I need to double check whether we actually consider lazy committing of OS pages for this metric or just assume that the full page has been mapped into memory.

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/16a572f1440000