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

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


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/14f5eff4240000

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

[oilpan] Enable incremental marking buildflag by mlippautz@chromium.org
https://chromium.googlesource.com/chromium/src/+/838fb3bd2db6a2869a0efc6e7e3154f954f74b70

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

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

The graphs that show a land/revert/reland pattern can definitely be attributed to the incremental marking CL. 

I started a bisect for one of the other graphs, as I don't see the pattern which seems a bit weird.

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

'JobState' object has no attribute '_comparison_mode'

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4024aad376eea8ef01d693a89dab09585b2a4f9e

commit 4024aad376eea8ef01d693a89dab09585b2a4f9e
Author: Michael Lippautz <mlippautz@chromium.org>
Date: Thu May 24 08:33:41 2018

[oilpan] Split write barrier in fast and slow parts

Split write barrier into fast and slow parts:
- The fast part only checks whether any Oilpan heap is currently marking. This
  check is only approximate as it does not consider the current ThreadState. In
  general, we expect this check to be enough to allow bailing out of the barrier.
- The slow version checks whether the current ThreadState is marking and whether
  the values actually require a write barrier.

This way we emit only a short instruction sequence for the fast cases and avoid
poluting the regular instruction sequences.

Verified locally on the microbenchmark blink_perf.parser query-selector-deep
which showed a 42% regression. Scores (higher is better):
- ToT: 8932
- Without barrier: 15188
- With this CL: 13352

Bug:  chromium:844576 ,  chromium:757440 
Change-Id: Ie8ebbf95fef0ff59ad8f1a111dd5daecfabc4109
Reviewed-on: https://chromium-review.googlesource.com/1071272
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Keishi Hattori <keishi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#561424}
[modify] https://crrev.com/4024aad376eea8ef01d693a89dab09585b2a4f9e/third_party/blink/renderer/platform/heap/marking_visitor.cc
[modify] https://crrev.com/4024aad376eea8ef01d693a89dab09585b2a4f9e/third_party/blink/renderer/platform/heap/marking_visitor.h
[modify] https://crrev.com/4024aad376eea8ef01d693a89dab09585b2a4f9e/third_party/blink/renderer/platform/heap/member.h
[modify] https://crrev.com/4024aad376eea8ef01d693a89dab09585b2a4f9e/third_party/blink/renderer/platform/heap/thread_state.h

Fixed for now. Most graphs recovered fully or almost. If there's time we can look into 'query-selector-all-class' specifically and optimize that one but that would be just optimizing for the benchmark and not the general case anymore.