GitLab

SharedImageBacking attributes its allocation to the MemoryTypeTracker of
its first SharedImageRepresentation which is considered its owning ref.
When the owning ref changes, the backing will switch the allocation to
the new owning ref's tracker.

This can happen on a different thread than the one the representation
was created on, and in general calling the underlying MemoryTracker is
not thread safe e.g. dereferencing the peak memory monitor's WeakPtr on
a different thread. This issue was discovered while testing the DrDC
prototype which makes the display's gpu work run on the viz thread
instead of the gpu main thread.

This CL fixes the above problem by making MemoryTypeTracker forward its
calls to its original sequence (and thus thread).  If a sequenced task
runner isn't set e.g. on the render thread on Android Webview, then the
calls are made synchronously.

Bug: 1114888
Change-Id: I6833139c96de3824f450b09333f755560dff62c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2350398
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: vikas soni <vikassoni@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/master@{#797841}