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

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


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

pixel_2_xl
pixel_xl

xr.browsing.wpr.static - Benchmark documentation link:
  None

This is surprising, but definitely possible. Are there any more details about this benchmark so I can get an idea what R8 is doing wrong?

All the benchmark is doing is loading some WPR archives of some popular sites (Google, Youtube, etc.) in the VR browser and measuring how much memory that takes. It's essentially a copy of the standard memory.top_10_mobile benchmark, but in VR. Unfortunately, it looks like the affected metric just reports 0 for that particular benchmark, so I can't check whether this is a VR-specific issue or a general Chrome one.

This regression is in the renderer process and GPU process. However, there is also a larger improvement in this metric for the browser process, which brings the all_processes benchmark to an improvement.

This is (I believe) caused by R8 making public builds 1 dex file again. In multidex experiments (https://docs.google.com/document/d/1EJR7cryCOxVW9G_r7_XnwscGP6FLU1UjhVNQROrJPHM/edit?usp=sharing), it was shown that going to multidex will improve GPU and renderer PSS, while it would hurt browser PSS. We had to go with multidex a few months ago on public builds because we ran out of method count, but now with R8 we are under the method count limit again. Therefore, we are no longer multidexed, and are therefore no longer paying the cost in the browser process, and are no longer getting the benefits in the GPU and renderer process.