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

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


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

android-nexus6
chromium-rel-mac11-pro

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

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

[ArrayBuffer] Give each SecurityOrigin a Partition for ArrayBuffers. by bbudge@chromium.org
chromium @ eaa730ff5abd585b0b629f07406df6701589e7ff

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

This looks like a significant performance regression. It is likely the overhead of converting the isolate to a SecurityOrigin.

Long term, we probably want V8 to provide extra information to speed up the association of ArrayBuffers with SecurityOrigins. There is ongoing debate in V8 about whether typed arrays and ArrayBuffers should be off-heap or on-heap (right now we have a combination of both.) Since that will take time to resolve, I think the right thing to do is revert this for now.

I'll prepare the revert CL.

Alternately, I could try to fix this slowdown by simplifying getting the key that maps allocations to partitions. Would isolate->context() or isolate->native_context() be equivalent?

Regressing patch was reverted.