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

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


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

android-nexus5x-perf

system_health.memory_mobile - Benchmark documentation link:
  https://bit.ly/system-health-benchmarks

memory.top_10_mobile - Benchmark documentation link:
  None

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15dc41efe40000

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

Lose context if we cannot make current by backer@chromium.org
https://chromium.googlesource.com/chromium/src/+/4adf9909bf15873e4ba4044d556a92e49f20284e
memory:chrome:all_processes:reported_by_os:system_memory:private_dirty_size: 7.525e+07 → 8.214e+07 (+6.89e+06)

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

Benchmark documentation link:
  https://bit.ly/system-health-benchmarks

backer@, could you take a look?

Looking right now.

My suspicion is that we are blocking less on MakeCurrent, causing less checkerboarding, causing more memory usage.

Unfortunately, metrics for N5X available from chromeperf.appspot.com don't seem to have mean_pixels_checkerboarded.

So I'm trying to repro locally...

I have a local repro. I need to flash my N5X to the same version of Android used on the bots: MMB29Q

I think that I understand what is happening.

Part of my change was to remove an unnecessary call to eglMakeCurrent. This unnecessary call used the same current context, but changed the current surface from an onscreen framebuffer to a 1x1 pixel offscreen surface. I believe that this triggered the driver to release some more memory associated with the framebuffer (e.g. a frontbuffer when double buffering).

I don't think that we should change the code though.

(1) We should generally avoid calls to eglMakeCurrent because the can stall our pipeline (e.g. trigger a mid frame flush on tilers or block until vblank).  The redundant eglMakeCurrent took 5 ms on one trace I was looking at.

(2) This problem does not reproduce on later versions of Android on the N5X, suggesting that the behaviour here is driver specific. Unless it is a major performance/correctness issue, we generally avoid special casing for driver/hardware versions.

(3) It's unclear how much this would affect users vs being an artifact of when we perform the memory dump during some tests.

Issue 908084 has been merged into this issue.