Invoke OnTrimMemoryImmediately when memory state is SUSPENDED

content/renderer/render_thread_impl.cc

Index: content/renderer/render_thread_impl.cc
diff --git a/content/renderer/render_thread_impl.cc b/content/renderer/render_thread_impl.cc
index d569350255fc98759f0de7ce89f7cd3374f98c42..21ac4aa6f154b4169a7c561dd1080c2b88eef4a4 100644
--- a/content/renderer/render_thread_impl.cc
+++ b/content/renderer/render_thread_impl.cc
@@ -1769,6 +1769,8 @@ void RenderThreadImpl::OnProcessPurgeAndSuspend() {
     // and follow MemoryCoordinator's request.
     base::MemoryCoordinatorClientRegistry::GetInstance()->Notify(
         base::MemoryState::SUSPENDED);
+    RenderThreadImpl::OnSyncMemoryPressure(

[bashi, 2016/11/11 07:45:23]

nit: Could you add a comment why we call this and future plan (integrate this
notification with memory coordinator) ?

[tasak, 2016/11/14 06:07:58]

Done.

+        base::MemoryPressureListener::MEMORY_PRESSURE_LEVEL_CRITICAL);

[haraken, 2016/11/11 08:58:40]

Just to confirm: This triggers Oilpan's GC too, right?

Also, we might want to call Partitions::decommitFreeableMemory() and some
clean-up method of tcmalloc (if any) after forcing the GCs.

[tasak, 2016/11/14 06:07:58]

Yes.
Manually tested purge+suspend without action_runner.ForceGarbageCollection().
I compared purge+suspend with just backgrounded (no purge and no suspend). v8
and blink_gc memory usages were reduced.
I think, currently we cannot control the order of "purge". Those methods are
invoked, but it is not possible to say the methods are invoked at last.

     renderer_scheduler_->SuspendRenderer();
   }