Move the mapped memory limit from the compositor to the GLHelper context

content/browser/renderer_host/compositor_impl_android.cc

Index: content/browser/renderer_host/compositor_impl_android.cc
diff --git a/content/browser/renderer_host/compositor_impl_android.cc b/content/browser/renderer_host/compositor_impl_android.cc
index e59169c49eee5c3ef61d84c8848c42f2d362073d..03062cb41cb9a2d789fbaa3c43e2c84370ca1be9 100644
--- a/content/browser/renderer_host/compositor_impl_android.cc
+++ b/content/browser/renderer_host/compositor_impl_android.cc
@@ -542,10 +542,6 @@ void CompositorImpl::CreateOutputSurface() {
       gfx::DeviceDisplayInfo().GetDisplayWidth() * kBytesPerPixel;
   limits.max_transfer_buffer_size = std::min(
       3 * full_screen_texture_size_in_bytes, kDefaultMaxTransferBufferSize);
-  // TODO(danakj): This limit should be on the GLHelper context instead in
-  // RWHVAndroid since that is where we do the async readback and map gpu
-  // memory to do so.
-  limits.mapped_memory_reclaim_limit = 2 * 1024 * 1024;

[no sievers, 2016/04/20 23:41:47]

I'm wondering if we should still leave some limit here. texImage2D() might still
use this in the fast-path and maybe other stuff that I missed.
And using kNoLimit just means that we can potentially get very high spikes in
shared memory usage which can trigger OOM killing.

[danakj, 2016/04/20 23:45:37]

Sure what limit would you like?

 
   scoped_refptr<ContextProviderCommandBuffer> context_provider(
       new ContextProviderCommandBuffer(