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

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


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

mac-10_12_laptop_low_end-perf
mac-10_13_laptop_high_end-perf

memory.desktop - Benchmark documentation link:
  None

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

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

cc: Avoid acquiring the context lock if unnecessary. by khushalsagar@chromium.org
https://chromium.googlesource.com/chromium/src/+/5d4e09620ff79ac668c72ad3677f993b75e617ce
memory:chrome:all_processes:reported_by_os:system_memory:private_footprint_size: 1.236e+08 → 1.278e+08 (+4.248e+06)

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

Benchmark documentation link:
  None

The change fixes a behaviour that was erroneously introduced by a previous change. And the regression is us going back to where we were before that change landed.