v8/test/inspector/heap-profiler/sampling-heap-profiler-flags.js

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

63 lines
2.3 KiB
JavaScript
Raw Normal View History

Add option to report discarded allocations in sampling heap profiler A couple of customers have asked about using devtools to get information about temporary allocations, with the goal of reducing GC time and/or peak memory usage. Currently, the sampling heap profiler reports only objects which are still alive at the end of the profiling session. In this change, I propose adding configuration options when starting the sampling heap profiler so that it can optionally include information about objects which were discarded by the GC before the end of the profiling session. A user could run the sampling heap profiler in several different modes depending on their goals: 1. To find memory leaks or determine which functions contribute most to steady-state memory consumption, the current default mode is best. 2. To find functions which cause large temporary memory spikes or large GC pauses, the user can request data about both live objects and those collected by major GC. 3. To tune for minimal GC activity in latency-sensitive applications like real-time audio processing, the user can request data about every allocation, including objects collected by major or minor GC. 4. I'm not sure why anybody would want data about objects collected by minor GC and not objects collected by major GC, but it's also a valid flags combination. Change-Id: If55d5965a1de04fed3ae640a02ca369723f64fdf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3868522 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#83202}
2022-09-08 16:27:54 +00:00
// Copyright 2017 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
// Flags: --sampling-heap-profiler-suppress-randomness
// Flags: --no-stress-incremental-marking
Add option to report discarded allocations in sampling heap profiler A couple of customers have asked about using devtools to get information about temporary allocations, with the goal of reducing GC time and/or peak memory usage. Currently, the sampling heap profiler reports only objects which are still alive at the end of the profiling session. In this change, I propose adding configuration options when starting the sampling heap profiler so that it can optionally include information about objects which were discarded by the GC before the end of the profiling session. A user could run the sampling heap profiler in several different modes depending on their goals: 1. To find memory leaks or determine which functions contribute most to steady-state memory consumption, the current default mode is best. 2. To find functions which cause large temporary memory spikes or large GC pauses, the user can request data about both live objects and those collected by major GC. 3. To tune for minimal GC activity in latency-sensitive applications like real-time audio processing, the user can request data about every allocation, including objects collected by major or minor GC. 4. I'm not sure why anybody would want data about objects collected by minor GC and not objects collected by major GC, but it's also a valid flags combination. Change-Id: If55d5965a1de04fed3ae640a02ca369723f64fdf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3868522 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#83202}
2022-09-08 16:27:54 +00:00
(async function() {
let {contextGroup, Protocol} = InspectorTest.start('Checks sampling heap profiler methods.');
contextGroup.addScript(`
function generateTrash() {
var arr = new Array(100);
for (var i = 0; i < 3000; ++i) {
var s = {a:i, b: new Array(100).fill(42)};
arr[i % 100] = s;
}
return arr[30];
}
//# sourceURL=test.js`);
Protocol.HeapProfiler.enable();
await Protocol.HeapProfiler.startSampling({
samplingInterval: 1e4,
includeObjectsCollectedByMajorGC: false,
includeObjectsCollectedByMinorGC: false,
});
await Protocol.Runtime.evaluate({ expression: 'generateTrash()' });
const profile1 = await Protocol.HeapProfiler.stopSampling();
const size1 = nodeSize(profile1.result.profile.head);
InspectorTest.log('Retained size is less than 10KB:', size1 < 10000);
await Protocol.HeapProfiler.startSampling({
samplingInterval: 100,
includeObjectsCollectedByMajorGC: true,
includeObjectsCollectedByMinorGC: false,
});
await Protocol.Runtime.evaluate({ expression: 'generateTrash()' });
const profile2 = await Protocol.HeapProfiler.stopSampling();
const size2 = nodeSize(profile2.result.profile.head);
InspectorTest.log('Including major GC increases size:', size1 < size2);
await Protocol.HeapProfiler.startSampling({
samplingInterval: 100,
includeObjectsCollectedByMajorGC: true,
includeObjectsCollectedByMinorGC: true,
});
await Protocol.Runtime.evaluate({ expression: 'generateTrash()' });
const profile3 = await Protocol.HeapProfiler.stopSampling();
const size3 = nodeSize(profile3.result.profile.head);
InspectorTest.log('Minor GC collected more:', size3 > size2);
InspectorTest.log('Total allocation is greater than 100KB:', size3 > 100000);
InspectorTest.log('Successfully finished');
InspectorTest.completeTest();
function nodeSize(node) {
return node.children.reduce((res, child) => res + nodeSize(child),
node.callFrame.functionName === 'generateTrash' ? node.selfSize : 0);
}
})();