GC triggered by memory pressure is postponed if V8 is busy |
||||||
Issue descriptionSteps to reproduce the problem: 1. surfing on low end Android device, like Samsung Galaxy Core2 2. after long time surfing, system memory becomes pressured and chrome will receive memory pressure notification 3. if V8 is in the middle of execution, renderer main thread has to postpone triggering V8 GC until V8 execution is finished, which increase OOM risk more discussion about the bug in below link: https://groups.google.com/a/chromium.org/forum/#!topic/project-trim/u_5DDPBXK74 What is the expected behavior? V8 can do GC ASAP if memory is pressured What went wrong? V8 doesn't do GC ASAP, which can increase OOM risk Did this work before? N/A Chrome version: 48.0.2564.116 Channel: n/a OS Version: 6.3 Flash Version: Shockwave Flash 20.0 r0 For example, from the attachments we can see, in www.airbnb.com webpage, OnMemoryPressure has about 1000ms lag The solution is WIP, I will update status soon
,
Mar 2 2016
I collected some traces with the CL in some web page, in which we found OnMemoryPressure had big lag(https://groups.google.com/a/chromium.org/d/msg/project-trim/u_5DDPBXK74/MPebAZSrAwAJ) From the trace we can see the CL reduces V8 GC lag obviously when memory is pressured
,
Mar 24 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/bb9b74e75495ff0d00897760f5f13784e88930b0 commit bb9b74e75495ff0d00897760f5f13784e88930b0 Author: ulan <ulan@chromium.org> Date: Thu Mar 24 09:51:44 2016 Add memory pressure notification API Based on CL 1777883002. BUG= chromium:590975 LOG=NO Review URL: https://codereview.chromium.org/1813963002 Cr-Commit-Position: refs/heads/master@{#35053} [modify] https://crrev.com/bb9b74e75495ff0d00897760f5f13784e88930b0/include/v8.h [modify] https://crrev.com/bb9b74e75495ff0d00897760f5f13784e88930b0/src/api.cc [modify] https://crrev.com/bb9b74e75495ff0d00897760f5f13784e88930b0/src/heap/heap.cc [modify] https://crrev.com/bb9b74e75495ff0d00897760f5f13784e88930b0/src/heap/heap.h [modify] https://crrev.com/bb9b74e75495ff0d00897760f5f13784e88930b0/src/heap/incremental-marking-job.cc [modify] https://crrev.com/bb9b74e75495ff0d00897760f5f13784e88930b0/src/heap/incremental-marking-job.h [modify] https://crrev.com/bb9b74e75495ff0d00897760f5f13784e88930b0/src/heap/incremental-marking.cc [modify] https://crrev.com/bb9b74e75495ff0d00897760f5f13784e88930b0/src/heap/incremental-marking.h [modify] https://crrev.com/bb9b74e75495ff0d00897760f5f13784e88930b0/test/cctest/test-api.cc
,
Mar 24 2016
,
Mar 25 2016
Does the MajorGC in those pages have a noticeable impact in memory usage? I'm curious how much doing the GC sooner really mattered.
,
Mar 28 2016
Is there API or tool to count the memory usage in V8? If yes, I would like to verify the impact.
,
Mar 29 2016
V8 is hooked up to the memory-infra tracing category. Long term, it's not sustainable to rely on memory pressure to ensure that we don't die.
,
Mar 29 2016
To add some more context: it might be that the system runs out of memory before v8 finishes the incremental GC. But if that happens, v8 didn't have the right memory limits configured. Doing a forced GC works around this issue, but doesn't solve it. Since the amount of available memory changes over time, the pressure notifications should come with a memory limit. Then v8 could decide based on the limit and current usage what to do, and can tune it's parameters to stay below the limit going forward.
,
Mar 30 2016
,
May 3 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f80422e52658fd87d4159bfeeddd703bae1d4180 commit f80422e52658fd87d4159bfeeddd703bae1d4180 Author: hong.zheng <hong.zheng@intel.com> Date: Tue May 03 04:23:37 2016 Do V8 GC ASAP if system memory is pressured Currently after receiving memory pressure notification, Chrome posts asynchronous task to renderer main thread to trigger V8 GC. If renderer main thread is busy, purging memory task will be postponed running, which increases OOM risk. The CL can send memory pressure notification to renderer main thread synchronously and trigger V8 GC while V8 is in the middle of executing JavaScript. The CL depends on CL 1813963002 BUG= 590975 Review-Url: https://codereview.chromium.org/1749073002 Cr-Commit-Position: refs/heads/master@{#391167} [modify] https://crrev.com/f80422e52658fd87d4159bfeeddd703bae1d4180/base/memory/memory_pressure_listener.cc [modify] https://crrev.com/f80422e52658fd87d4159bfeeddd703bae1d4180/base/memory/memory_pressure_listener.h [modify] https://crrev.com/f80422e52658fd87d4159bfeeddd703bae1d4180/content/renderer/render_thread_impl.cc [modify] https://crrev.com/f80422e52658fd87d4159bfeeddd703bae1d4180/content/renderer/render_thread_impl.h [modify] https://crrev.com/f80422e52658fd87d4159bfeeddd703bae1d4180/third_party/WebKit/Source/core/workers/WorkerBackingThread.cpp [modify] https://crrev.com/f80422e52658fd87d4159bfeeddd703bae1d4180/third_party/WebKit/Source/core/workers/WorkerBackingThread.h [modify] https://crrev.com/f80422e52658fd87d4159bfeeddd703bae1d4180/third_party/WebKit/Source/web/WebKit.cpp [modify] https://crrev.com/f80422e52658fd87d4159bfeeddd703bae1d4180/third_party/WebKit/public/web/WebKit.h
,
May 4 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/78980b9332da0264f52bd4ff0b6aeef23cdc21e9 commit 78980b9332da0264f52bd4ff0b6aeef23cdc21e9 Author: vitalybuka <vitalybuka@chromium.org> Date: Wed May 04 20:50:48 2016 Revert of Do V8 GC ASAP if system memory is pressured (patchset #13 id:240001 of https://codereview.chromium.org/1749073002/ ) Reason for revert: Crash in CallOnForegroundThread BUG=609056 Original issue's description: > Do V8 GC ASAP if system memory is pressured > > Currently after receiving memory pressure notification, Chrome posts > asynchronous task to renderer main thread to trigger V8 GC. If renderer > main thread is busy, purging memory task will be postponed running, > which increases OOM risk. > > The CL can send memory pressure notification to renderer main thread > synchronously and trigger V8 GC while V8 is in the middle of executing > JavaScript. > > The CL depends on CL 1813963002 > > BUG= 590975 > > Committed: https://crrev.com/f80422e52658fd87d4159bfeeddd703bae1d4180 > Cr-Commit-Position: refs/heads/master@{#391167} TBR=esprehn@chromium.org,jochen@chromium.org,kinuko@chromium.org,mark@chromium.org,rmcilroy@chromium.org,ulan@chromium.org,hong.zheng@intel.com # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= 590975 Review-Url: https://codereview.chromium.org/1953483002 Cr-Commit-Position: refs/heads/master@{#391636} [modify] https://crrev.com/78980b9332da0264f52bd4ff0b6aeef23cdc21e9/base/memory/memory_pressure_listener.cc [modify] https://crrev.com/78980b9332da0264f52bd4ff0b6aeef23cdc21e9/base/memory/memory_pressure_listener.h [modify] https://crrev.com/78980b9332da0264f52bd4ff0b6aeef23cdc21e9/content/renderer/render_thread_impl.cc [modify] https://crrev.com/78980b9332da0264f52bd4ff0b6aeef23cdc21e9/content/renderer/render_thread_impl.h [modify] https://crrev.com/78980b9332da0264f52bd4ff0b6aeef23cdc21e9/third_party/WebKit/Source/core/workers/WorkerBackingThread.cpp [modify] https://crrev.com/78980b9332da0264f52bd4ff0b6aeef23cdc21e9/third_party/WebKit/Source/core/workers/WorkerBackingThread.h [modify] https://crrev.com/78980b9332da0264f52bd4ff0b6aeef23cdc21e9/third_party/WebKit/Source/web/WebKit.cpp [modify] https://crrev.com/78980b9332da0264f52bd4ff0b6aeef23cdc21e9/third_party/WebKit/public/web/WebKit.h
,
May 11 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b28b53323cf9a4e487e081a63b546c210f4878b2 commit b28b53323cf9a4e487e081a63b546c210f4878b2 Author: hong.zheng <hong.zheng@intel.com> Date: Wed May 11 02:33:39 2016 Do V8 GC ASAP if system memory is pressured[reland] Remove worker thread isolate before V8PerIsolateData::destroy This is a reland of https://codereview.chromium.org/1749073002/ BUG= 590975 Review-Url: https://codereview.chromium.org/1949153003 Cr-Commit-Position: refs/heads/master@{#392833} [modify] https://crrev.com/b28b53323cf9a4e487e081a63b546c210f4878b2/base/memory/memory_pressure_listener.cc [modify] https://crrev.com/b28b53323cf9a4e487e081a63b546c210f4878b2/base/memory/memory_pressure_listener.h [modify] https://crrev.com/b28b53323cf9a4e487e081a63b546c210f4878b2/content/renderer/render_thread_impl.cc [modify] https://crrev.com/b28b53323cf9a4e487e081a63b546c210f4878b2/content/renderer/render_thread_impl.h [modify] https://crrev.com/b28b53323cf9a4e487e081a63b546c210f4878b2/third_party/WebKit/Source/core/workers/WorkerBackingThread.cpp [modify] https://crrev.com/b28b53323cf9a4e487e081a63b546c210f4878b2/third_party/WebKit/Source/core/workers/WorkerBackingThread.h [modify] https://crrev.com/b28b53323cf9a4e487e081a63b546c210f4878b2/third_party/WebKit/Source/web/WebKit.cpp [modify] https://crrev.com/b28b53323cf9a4e487e081a63b546c210f4878b2/third_party/WebKit/public/web/WebKit.h
,
Mar 1 2017
hong.zheng@, can we close this issue?
,
Mar 2 2017
,
Apr 16 2018
What thread RenderThreadImpl::OnSyncMemoryPressure() is supposed to be called on? On Android it'll be called on Android main thread (where Android delivers memory pressure signals), and not on CrRendererMain. Is this a problem? I don't see any locks or thread checks in OnSyncMemoryPressure()... |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by hong.zh...@intel.com
, Mar 1 2016