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

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


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

chromium-rel-mac11-pro
win-high-dpi

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

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

Reland "[heap] Mark RO_SPACE as read-only after deserialization" by delphick@chromium.org
https://chromium.googlesource.com/v8/v8/+/600641338d160ce2dc82d3cdec0f414946409b81

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

This is the test: https://cs.chromium.org/chromium/src/third_party/blink/perf_tests/bindings/set-attribute-rare.html

Aside from making the pages themselves read-only which I couldn't imagine giving such a drop in perf, that change also prevented RO_SPACE strings from being externalized since that's a mutating operation:

https://chromium-review.googlesource.com/c/v8/v8/+/1042145/9/src/objects.cc

The test there does use the string "group" which is an internalized string that would appear in RO_SPACE: https://cs.chromium.org/chromium/src/v8/src/heap-symbols.h?l=92&rcl=44d7d7d6b1041b57644400a00cb3fee35f6c51b2

However there's also a regression in the set-attribute benchmark which doesn't contain an RO_SPACE string (at least as a literal).

I don't think this is a real issue as I couldn't reproduce myself.