Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2496863003:
Invoke OnTrimMemoryImmediately when memory state is SUSPENDED (Closed)
DescriptionInvoke OnTrimMemoryImmediately when memory state is SUSPENDED
When memory state is changed to be SUSPENDED, invoke v8 GC via OnTrimMemoryImmediately.
It is important to reduce renderer's memory when suspended.
- Purge+Suspend is controlled by base::Feature::kPurgeAndSuspend (c.f. @430225), and is disabled by default.
- intent-to-implement-and-ship of background renderer's purge+suspend is
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/DK189tnM8l4
- one of the documents attached in the above intent is
https://docs.google.com/document/d/1EgLimgxWK5DGhptnNVbEGSvVn6Q609ZJaBkLjEPRJvI/edit?usp=sharing
BUG=607077
Committed: https://crrev.com/61b4aeba94c28323a9db0b338aa13112759ab47c
Cr-Commit-Position: refs/heads/master@{#433793}
Patch Set 1 #
Total comments: 4
Patch Set 2 : Add comment. #Patch Set 3 : Move V8 GC call to OnMemoryStateChange #Patch Set 4 : Rebaselined #Messages
Total messages: 45 (27 generated)
The CQ bit was checked by tasak@google.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
tasak@google.com changed reviewers: + bashi@chromium.org, haraken@chromium.org
Would you review this CL?
non-owner lgtm https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... File content/renderer/render_thread_impl.cc (right): https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... content/renderer/render_thread_impl.cc:1772: RenderThreadImpl::OnSyncMemoryPressure( nit: Could you add a comment why we call this and future plan (integrate this notification with memory coordinator) ?
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... File content/renderer/render_thread_impl.cc (right): https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... content/renderer/render_thread_impl.cc:1773: base::MemoryPressureListener::MEMORY_PRESSURE_LEVEL_CRITICAL); 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.
The CQ bit was checked by tasak@google.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Thank you for review. https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... File content/renderer/render_thread_impl.cc (right): https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... content/renderer/render_thread_impl.cc:1772: RenderThreadImpl::OnSyncMemoryPressure( On 2016/11/11 07:45:23, bashi1 wrote: > nit: Could you add a comment why we call this and future plan (integrate this > notification with memory coordinator) ? Done. https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... content/renderer/render_thread_impl.cc:1773: base::MemoryPressureListener::MEMORY_PRESSURE_LEVEL_CRITICAL); On 2016/11/11 08:58:40, haraken wrote: > > Just to confirm: This triggers Oilpan's GC too, right? 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. > Also, we might want to call Partitions::decommitFreeableMemory() and some > clean-up method of tcmalloc (if any) after forcing the GCs. 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.
On 2016/11/14 06:07:58, tasak wrote: > Thank you for review. > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > File content/renderer/render_thread_impl.cc (right): > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > content/renderer/render_thread_impl.cc:1772: > RenderThreadImpl::OnSyncMemoryPressure( > On 2016/11/11 07:45:23, bashi1 wrote: > > nit: Could you add a comment why we call this and future plan (integrate this > > notification with memory coordinator) ? > > Done. > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > content/renderer/render_thread_impl.cc:1773: > base::MemoryPressureListener::MEMORY_PRESSURE_LEVEL_CRITICAL); > On 2016/11/11 08:58:40, haraken wrote: > > > > Just to confirm: This triggers Oilpan's GC too, right? > > 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. > > > Also, we might want to call Partitions::decommitFreeableMemory() and some > > clean-up method of tcmalloc (if any) after forcing the GCs. > > 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. Instead of calling onSyncMemoryPressure() in OnProcessPurgeAndSuspend, does it make sense to call OnTrimMemoryImmediately() in OnMemoryStateChange()? I guess that it allows us to run them in the order we want.
On 2016/11/14 06:21:22, bashi1 wrote: > On 2016/11/14 06:07:58, tasak wrote: > > Thank you for review. > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > File content/renderer/render_thread_impl.cc (right): > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > content/renderer/render_thread_impl.cc:1772: > > RenderThreadImpl::OnSyncMemoryPressure( > > On 2016/11/11 07:45:23, bashi1 wrote: > > > nit: Could you add a comment why we call this and future plan (integrate > this > > > notification with memory coordinator) ? > > > > Done. > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > content/renderer/render_thread_impl.cc:1773: > > base::MemoryPressureListener::MEMORY_PRESSURE_LEVEL_CRITICAL); > > On 2016/11/11 08:58:40, haraken wrote: > > > > > > Just to confirm: This triggers Oilpan's GC too, right? > > > > 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. > > > > > Also, we might want to call Partitions::decommitFreeableMemory() and some > > > clean-up method of tcmalloc (if any) after forcing the GCs. > > > > 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. > > Instead of calling onSyncMemoryPressure() in OnProcessPurgeAndSuspend, does it > make sense to call OnTrimMemoryImmediately() in OnMemoryStateChange()? I guess > that it allows us to run them in the order we want. Yes, as discussed offline (search an email titled "MemoryCoordinator and V8 reducer"), our plan is to control the order manually in RenderThreadImpl, instead of introducing some ordering rule to MemoryCoordinator's callbacks.
On 2016/11/14 07:17:22, haraken wrote: > On 2016/11/14 06:21:22, bashi1 wrote: > > On 2016/11/14 06:07:58, tasak wrote: > > > Thank you for review. > > > > > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > > File content/renderer/render_thread_impl.cc (right): > > > > > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > > content/renderer/render_thread_impl.cc:1772: > > > RenderThreadImpl::OnSyncMemoryPressure( > > > On 2016/11/11 07:45:23, bashi1 wrote: > > > > nit: Could you add a comment why we call this and future plan (integrate > > this > > > > notification with memory coordinator) ? > > > > > > Done. > > > > > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > > content/renderer/render_thread_impl.cc:1773: > > > base::MemoryPressureListener::MEMORY_PRESSURE_LEVEL_CRITICAL); > > > On 2016/11/11 08:58:40, haraken wrote: > > > > > > > > Just to confirm: This triggers Oilpan's GC too, right? > > > > > > 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. > > > > > > > Also, we might want to call Partitions::decommitFreeableMemory() and some > > > > clean-up method of tcmalloc (if any) after forcing the GCs. > > > > > > 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. > > > > Instead of calling onSyncMemoryPressure() in OnProcessPurgeAndSuspend, does it > > make sense to call OnTrimMemoryImmediately() in OnMemoryStateChange()? I guess > > that it allows us to run them in the order we want. > > Yes, as discussed offline (search an email titled "MemoryCoordinator and V8 > reducer"), our plan is to control the order manually in RenderThreadImpl, > instead of introducing some ordering rule to MemoryCoordinator's callbacks. So the change affects OnMemoryStateChange... MemoryCoordinator v0. bashi-san, is it ok to add v8 gc call to RenderThreadImpl::OnMemoryStateChange? I'm afraid that it breaks something of MemoryCoordinator v0 design.
On 2016/11/14 09:46:54, tasak wrote: > On 2016/11/14 07:17:22, haraken wrote: > > On 2016/11/14 06:21:22, bashi1 wrote: > > > On 2016/11/14 06:07:58, tasak wrote: > > > > Thank you for review. > > > > > > > > > > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > > > File content/renderer/render_thread_impl.cc (right): > > > > > > > > > > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > > > content/renderer/render_thread_impl.cc:1772: > > > > RenderThreadImpl::OnSyncMemoryPressure( > > > > On 2016/11/11 07:45:23, bashi1 wrote: > > > > > nit: Could you add a comment why we call this and future plan (integrate > > > this > > > > > notification with memory coordinator) ? > > > > > > > > Done. > > > > > > > > > > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > > > content/renderer/render_thread_impl.cc:1773: > > > > base::MemoryPressureListener::MEMORY_PRESSURE_LEVEL_CRITICAL); > > > > On 2016/11/11 08:58:40, haraken wrote: > > > > > > > > > > Just to confirm: This triggers Oilpan's GC too, right? > > > > > > > > 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. > > > > > > > > > Also, we might want to call Partitions::decommitFreeableMemory() and > some > > > > > clean-up method of tcmalloc (if any) after forcing the GCs. > > > > > > > > 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. > > > > > > Instead of calling onSyncMemoryPressure() in OnProcessPurgeAndSuspend, does > it > > > make sense to call OnTrimMemoryImmediately() in OnMemoryStateChange()? I > guess > > > that it allows us to run them in the order we want. > > > > Yes, as discussed offline (search an email titled "MemoryCoordinator and V8 > > reducer"), our plan is to control the order manually in RenderThreadImpl, > > instead of introducing some ordering rule to MemoryCoordinator's callbacks. > > So the change affects OnMemoryStateChange... MemoryCoordinator v0. > > bashi-san, is it ok to add v8 gc call to RenderThreadImpl::OnMemoryStateChange? > I'm afraid that it breaks something of MemoryCoordinator v0 design. Sorry not being clear. Yes, I'm totally fine with modifying OnMemoryStateChange(). It will change the behaviour of memory coordinator but that's what we want to do :)
The CQ bit was checked by tasak@google.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
On 2016/11/14 12:19:45, bashi1 wrote: > On 2016/11/14 09:46:54, tasak wrote: > > On 2016/11/14 07:17:22, haraken wrote: > > > On 2016/11/14 06:21:22, bashi1 wrote: > > > > On 2016/11/14 06:07:58, tasak wrote: > > > > > Thank you for review. > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > > > > File content/renderer/render_thread_impl.cc (right): > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > > > > content/renderer/render_thread_impl.cc:1772: > > > > > RenderThreadImpl::OnSyncMemoryPressure( > > > > > On 2016/11/11 07:45:23, bashi1 wrote: > > > > > > nit: Could you add a comment why we call this and future plan > (integrate > > > > this > > > > > > notification with memory coordinator) ? > > > > > > > > > > Done. > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > > > > content/renderer/render_thread_impl.cc:1773: > > > > > base::MemoryPressureListener::MEMORY_PRESSURE_LEVEL_CRITICAL); > > > > > On 2016/11/11 08:58:40, haraken wrote: > > > > > > > > > > > > Just to confirm: This triggers Oilpan's GC too, right? > > > > > > > > > > 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. > > > > > > > > > > > Also, we might want to call Partitions::decommitFreeableMemory() and > > some > > > > > > clean-up method of tcmalloc (if any) after forcing the GCs. > > > > > > > > > > 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. > > > > > > > > Instead of calling onSyncMemoryPressure() in OnProcessPurgeAndSuspend, > does > > it > > > > make sense to call OnTrimMemoryImmediately() in OnMemoryStateChange()? I > > guess > > > > that it allows us to run them in the order we want. > > > > > > Yes, as discussed offline (search an email titled "MemoryCoordinator and V8 > > > reducer"), our plan is to control the order manually in RenderThreadImpl, > > > instead of introducing some ordering rule to MemoryCoordinator's callbacks. > > > > So the change affects OnMemoryStateChange... MemoryCoordinator v0. > > > > bashi-san, is it ok to add v8 gc call to > RenderThreadImpl::OnMemoryStateChange? > > I'm afraid that it breaks something of MemoryCoordinator v0 design. > > Sorry not being clear. Yes, I'm totally fine with modifying > OnMemoryStateChange(). It will change the behaviour of memory coordinator but > that's what we want to do :) Thank you, bashi-san. I modified OnMemoryStateChange instead of OnProcessPurgeAndSuspend.
Patchset #3 (id:40001) has been deleted
The CQ bit was checked by tasak@google.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
On 2016/11/15 02:26:36, tasak wrote: > On 2016/11/14 12:19:45, bashi1 wrote: > > On 2016/11/14 09:46:54, tasak wrote: > > > On 2016/11/14 07:17:22, haraken wrote: > > > > On 2016/11/14 06:21:22, bashi1 wrote: > > > > > On 2016/11/14 06:07:58, tasak wrote: > > > > > > Thank you for review. > > > > > > > > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > > > > > File content/renderer/render_thread_impl.cc (right): > > > > > > > > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > > > > > content/renderer/render_thread_impl.cc:1772: > > > > > > RenderThreadImpl::OnSyncMemoryPressure( > > > > > > On 2016/11/11 07:45:23, bashi1 wrote: > > > > > > > nit: Could you add a comment why we call this and future plan > > (integrate > > > > > this > > > > > > > notification with memory coordinator) ? > > > > > > > > > > > > Done. > > > > > > > > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2496863003/diff/1/content/renderer/render_thr... > > > > > > content/renderer/render_thread_impl.cc:1773: > > > > > > base::MemoryPressureListener::MEMORY_PRESSURE_LEVEL_CRITICAL); > > > > > > On 2016/11/11 08:58:40, haraken wrote: > > > > > > > > > > > > > > Just to confirm: This triggers Oilpan's GC too, right? > > > > > > > > > > > > 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. > > > > > > > > > > > > > Also, we might want to call Partitions::decommitFreeableMemory() and > > > some > > > > > > > clean-up method of tcmalloc (if any) after forcing the GCs. > > > > > > > > > > > > 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. > > > > > > > > > > Instead of calling onSyncMemoryPressure() in OnProcessPurgeAndSuspend, > > does > > > it > > > > > make sense to call OnTrimMemoryImmediately() in OnMemoryStateChange()? I > > > guess > > > > > that it allows us to run them in the order we want. > > > > > > > > Yes, as discussed offline (search an email titled "MemoryCoordinator and > V8 > > > > reducer"), our plan is to control the order manually in RenderThreadImpl, > > > > instead of introducing some ordering rule to MemoryCoordinator's > callbacks. > > > > > > So the change affects OnMemoryStateChange... MemoryCoordinator v0. > > > > > > bashi-san, is it ok to add v8 gc call to > > RenderThreadImpl::OnMemoryStateChange? > > > I'm afraid that it breaks something of MemoryCoordinator v0 design. > > > > Sorry not being clear. Yes, I'm totally fine with modifying > > OnMemoryStateChange(). It will change the behaviour of memory coordinator but > > that's what we want to do :) > > Thank you, bashi-san. > > I modified OnMemoryStateChange instead of OnProcessPurgeAndSuspend. Thanks! lgtm.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
LGTM
tasak@google.com changed reviewers: + avi@chromium.org
avi, would you review this CL?
The CQ bit was checked by tasak@google.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Description was changed from ========== Invoke RenderThreadImpl::OnSyncMemoryPressure when suspended Since currently v8 isolate is not a MemoryCoordinator client, need to use MemoryPressure to reduce v8 memory. - Purge+Suspend is controlled by base::Feature::kPurgeAndSuspend (c.f. @430225), and is disabled by default. - intent-to-implement-and-ship of background renderer's purge+suspend is https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/DK189tnM8l4 - one of the documents attached in the above intent is https://docs.google.com/document/d/1EgLimgxWK5DGhptnNVbEGSvVn6Q609ZJaBkLjEPRJ... BUG=607077 ========== to ========== Invoke OnTrimMemoryImmediately when memory state is SUSPENDED When memory state is changed to be SUSPENDED, invoke v8 GC via OnTrimMemoryImmediately. It is important to reduce renderer's memory when suspended. - Purge+Suspend is controlled by base::Feature::kPurgeAndSuspend (c.f. @430225), and is disabled by default. - intent-to-implement-and-ship of background renderer's purge+suspend is https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/DK189tnM8l4 - one of the documents attached in the above intent is https://docs.google.com/document/d/1EgLimgxWK5DGhptnNVbEGSvVn6Q609ZJaBkLjEPRJ... BUG=607077 ==========
avi, would you review this CL? This CL is adding one line to render_thread_impl.cc. I need content/ owner's lgtm.
LGTM Please wait only one business day before poking me if I miss your review.
Thank you for review. On 2016/11/22 04:58:34, Avi wrote: > LGTM > > Please wait only one business day before poking me if I miss your review. I see.
The CQ bit was checked by tasak@google.com
The patchset sent to the CQ was uploaded after l-g-t-m from haraken@chromium.org, bashi@chromium.org Link to the patchset: https://codereview.chromium.org/2496863003/#ps80001 (title: "Rebaselined")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 80001, "attempt_start_ts": 1479791189426520,
"parent_rev": "0f2a81b5c94e86d8d94f0b526dd3f0fa2822e96a", "commit_rev":
"c0b6822795af09f40dc00b4bc238c63df20ea3e1"}
Message was sent while issue was closed.
Description was changed from ========== Invoke OnTrimMemoryImmediately when memory state is SUSPENDED When memory state is changed to be SUSPENDED, invoke v8 GC via OnTrimMemoryImmediately. It is important to reduce renderer's memory when suspended. - Purge+Suspend is controlled by base::Feature::kPurgeAndSuspend (c.f. @430225), and is disabled by default. - intent-to-implement-and-ship of background renderer's purge+suspend is https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/DK189tnM8l4 - one of the documents attached in the above intent is https://docs.google.com/document/d/1EgLimgxWK5DGhptnNVbEGSvVn6Q609ZJaBkLjEPRJ... BUG=607077 ========== to ========== Invoke OnTrimMemoryImmediately when memory state is SUSPENDED When memory state is changed to be SUSPENDED, invoke v8 GC via OnTrimMemoryImmediately. It is important to reduce renderer's memory when suspended. - Purge+Suspend is controlled by base::Feature::kPurgeAndSuspend (c.f. @430225), and is disabled by default. - intent-to-implement-and-ship of background renderer's purge+suspend is https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/DK189tnM8l4 - one of the documents attached in the above intent is https://docs.google.com/document/d/1EgLimgxWK5DGhptnNVbEGSvVn6Q609ZJaBkLjEPRJ... BUG=607077 ==========
Message was sent while issue was closed.
Committed patchset #4 (id:80001)
Message was sent while issue was closed.
Description was changed from ========== Invoke OnTrimMemoryImmediately when memory state is SUSPENDED When memory state is changed to be SUSPENDED, invoke v8 GC via OnTrimMemoryImmediately. It is important to reduce renderer's memory when suspended. - Purge+Suspend is controlled by base::Feature::kPurgeAndSuspend (c.f. @430225), and is disabled by default. - intent-to-implement-and-ship of background renderer's purge+suspend is https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/DK189tnM8l4 - one of the documents attached in the above intent is https://docs.google.com/document/d/1EgLimgxWK5DGhptnNVbEGSvVn6Q609ZJaBkLjEPRJ... BUG=607077 ========== to ========== Invoke OnTrimMemoryImmediately when memory state is SUSPENDED When memory state is changed to be SUSPENDED, invoke v8 GC via OnTrimMemoryImmediately. It is important to reduce renderer's memory when suspended. - Purge+Suspend is controlled by base::Feature::kPurgeAndSuspend (c.f. @430225), and is disabled by default. - intent-to-implement-and-ship of background renderer's purge+suspend is https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/DK189tnM8l4 - one of the documents attached in the above intent is https://docs.google.com/document/d/1EgLimgxWK5DGhptnNVbEGSvVn6Q609ZJaBkLjEPRJ... BUG=607077 Committed: https://crrev.com/61b4aeba94c28323a9db0b338aa13112759ab47c Cr-Commit-Position: refs/heads/master@{#433793} ==========
Message was sent while issue was closed.
Patchset 4 (id:??) landed as https://crrev.com/61b4aeba94c28323a9db0b338aa13112759ab47c Cr-Commit-Position: refs/heads/master@{#433793} |
