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

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


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

webrtc-win-large-tests

Patrik, this roll couldn't have change the tests order or some other testing configuration, right?

I don't think it would change the test order, but tests should not make assumptions about in which order other tests execute anyway.

Chromium rolls can and will change the build system and test execution environment however. WebRTC production code doesn't directly depend on any chromium code, so the only possibility of this being a real issue is that the build system changed in such a way that the production code is using more memory, or if one of our third party libs use more memory (such as libyuv or libvpx).

Let's look at third parties that were rolled in this CL. BoringSSL:
- I guess this one could be suspect: https://boringssl.googlesource.com/boringssl.git/+/b570fd9fd6b47c31ae0014f1cdc748f7a4634d81
- No other ideas

Libvpx:
- No obvious culprits, not sure what to look for

Libyuv:
- Maybe https://chromium.googlesource.com/libyuv/libyuv.git/+/083aa718b9297326eb969fc6c2b3607080714bc8%5E%21/#F2?

Finally, it could be a win build system or test harness change. The former sounds unlikely; I can't find an obvious culprit in https://chromium.googlesource.com/chromium/src/build/+log/169887d089..f29a733cc2. I can't find anything on Windows or memory in the //testing changelog either: https://chromium.googlesource.com/chromium/src/testing/+log/5951b2830b..04314205f8

I would say this is highly inconclusive, most probably a WontFix unless someone makes a genius analysis. If you want to dig deeper into the libvpx or other 3pp changes, go for it.

As of https://webrtc.googlesource.com/src/+/b4dfdf574d31cf79b771199836584f1d1a4357a0 memory consumption went back.