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

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


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

pixel_2_xl
pixel_xl

I had an offline discussion about this test with bsheedy@:

"loads some archived web pages in the VR browser mostly the same pages as memory.top_10_mobile. Essentially all it does is measure the memory usage when viewing a static web page (no scrolling or anything)".

This is likely at least partially a memory accounting issue but the 33500% regression looks very concerning. 

Note that while some of the percentage increases are quite large, the absolute increase is only a few megabytes. Still worth looking into, but not nearly as bad as it sounds.

Dug into this - it isn't actually a real issue - basically, memory moved from the browser process to the GPU process, but overall, memory was generally the same. See: 
https://chromeperf.appspot.com/report?sid=7b4ed61e30759d51cab3ea888ca669d57d661f82faa46d4981cfc9f1e42690fe&start_rev=583249&end_rev=593143

In some cases it's harder to see the movement, as memory moved from SharedMemory to Malloc memory (as in-process command buffer doesn't need shared mem to communicate), but the cases I looked at all seemed to be 1:1 transfers from one category to another.