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

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


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

android-nexus5
android-one
chromium-rel-mac11-air
chromium-rel-mac11-pro
linux-perf

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

📍 Found significant differences after each of 5 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/12ea17b4240000

Roll AFDO from 68.0.3430.0_rc-r1 to 68.0.3431.0_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/ed75d2932ed7eaf95fafa505007de464316dbb0b

Replace MoveResourceLoaderNonBlocking CHECK with DCHECK by yoav@yoav.ws
https://chromium.googlesource.com/chromium/src/+/cb1d73966b7fff0bd5a28a64514b2ab4ced0ea81

[hash-table] Inline GetHash and GetSimpleHash by gsathya@chromium.org
https://chromium.googlesource.com/v8/v8/+/0e8b67ce7f04115cc56903178f277cba75efbc21

Update V8 to version 6.8.225. by v8-autoroll@chromium.org
https://chromium.googlesource.com/chromium/src/+/7e54a0b17cab5f74d0a79b0069718b76205c97d3

service worker: Enable ServiceWorkerRegistration#updateViaCache by default. by falken@chromium.org
https://chromium.googlesource.com/chromium/src/+/39970a79fb0f27170b039a0eb371ed8c36ece484

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

I don't think this can be my change which only affects service worker updates. The regressed test is single-select-add and textarea-dom which I don't expect to use service workers.

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

The large jump in the graph occurs at 558621 (https://crrev.com/c/1058846).

The perf benchmark in an android one and the CL is changing the rev of something on Android.

Assigning to gbiv@ as the sheriff.

I feel like I've received more bugs for AFDO rolls in random blink bits in the last week than I have since it landed in January. :)

So, for background, AFDO changes how the compiler decides to optimize by feeding samples of how Chrome executes back into the compiler. Since blink benchmarks, AIUI, are pretty sensitive to individual optimization decisions, noise in the profile gathering process can cause swings every now and then. So, this regression might disappear in one of the next few rolls, which happen roughly daily.

That said, my goal at the moment is to find a way to make the blink flakiness with AFDO stop. Even if this fixes itself, I'll try to fold it into that effort.

In this case, I only see three substantial instances of presumably-AFDO-caused-flakiness since we landed AFDO 5ish months ago.

(I'm also unsure if the select-single-add regression is caused by AFDO, since the AFDO rolls near it were in `560068 - 560141`, which was after the drop and `558202 - 558245`, which was a point before the large drop. I'll look into it to confirm.)

📍 Found significant differences after each of 4 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/14dceafc240000

Add use counter for sorting non-packed JSArrays by szuend@google.com
https://chromium.googlesource.com/chromium/src/+/07c9bc6ed5c27bfedee1d7f52ed7f732c6af9e81

Enable sdpSemantic RTCPeerConnection parameter by hta@chromium.org
https://chromium.googlesource.com/chromium/src/+/02bd2d220545367bbad5f2dd02d78f1d50836cec

Initial handling of bloated V8 heaps near the heap limit. by ulan@chromium.org
https://chromium.googlesource.com/chromium/src/+/fc84822a48a47a20858c43f794b408a156df97d1

Split ContentInputDelegate to PlatformUiInputDelegate and ContentInputDelegate by bshe@chromium.org
https://chromium.googlesource.com/chromium/src/+/41db7d269b73979eaf2bbc24e457319da7c74b15

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

My CL didn't touch blink code and it was a simple refactor. It shouldn't affect blink perf. The other three CLs all changed blink. Not sure which one is more likely. Randomly select hta@. It looks like you enabled a new feature in the list CL above, do you mind to take a look?

The flag flip only exposed the flag - its default value didn't change - so shouldn't have any effect.
Randomly passing the baton to ulan@.

My CL is behind a flag and is a no-op for bots.

In any case, looks like the graphs have recovered. Closing the issue.