Issue metadata
Sign in to add a comment
|
System health memory benchmarks don't force a Java/Oilpan GC |
||||||||||||||||||||||
Issue descriptionThe system health memory benchmarks currently only do a v8 GC before measuring memory: https://cs.chromium.org/chromium/src/third_party/catapult/telemetry/telemetry/internal/actions/action_runner.py?rcl=2310cee321893cda629902dcdaa32f38ad2e7c35&l=154 Should we also do an Oilpan and/or Java GC here?
,
Mar 21 2017
More context -- here's what implements that: https://cs.chromium.org/chromium/src/v8/src/inspector/v8-heap-profiler-agent-impl.cc?rcl=f80439646ae20f2328d82659dcc38fd154441eec&l=176
,
Mar 27 2017
I thought that v8 full gcs cause in turn an oilpan GC these days (+haraken)? Instead we have Java (Android) uncovered. But that should be as easy as either System.gc() or kill(getpid(), SIGUSR1) (internally SIGUSR1 is handled by Art and causes a GC [1]) [1] https://android.googlesource.com/platform/art/+/0795f23/runtime/signal_catcher.cc#156
,
Mar 27 2017
> I thought that v8 full gcs cause in turn an oilpan GC these days (+haraken)? Not always but it's highly likely that an Oilpan GC will follow the V8 GC in the near future (in a separate task).
,
Mar 27 2017
Ah, if you use window.gc() (or any other APIs to force a V8 GC), an Oilpan GC is guaranteed to follow the V8 GC.
,
Mar 27 2017
Right now this is using #2, which ends up with:
V8HeapProfilerAgentImpl::collectGarbage()
Isolate::LowMemoryNotification()
Heap::CollectAllAvailableGarbage(kLowMemoryNotification)
,
Mar 27 2017
Then Oipan's GC should follow. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by perezju@chromium.org
, Mar 21 2017