mirror of
https://github.com/nodejs/node.git
synced 2025-05-15 21:44:51 +00:00
b7bbd871af
Original commit message 9365d09:
[coverage] Rework continuation counter handling
This changes a few bits about how continuation counters are handled.
It introduces a new mechanism that allows removal of a continuation
range after it has been created. If coverage is enabled, we run a first
post-processing pass on the AST immediately after parsing, which
removes problematic continuation ranges in two situations:
1. nested continuation counters - only the outermost stays alive.
2. trailing continuation counters within a block-like structure are
removed if the containing structure itself has a continuation.
R=bmeurer@chromium.org, jgruber@chromium.org, yangguo@chromium.org
Bug: v8:8381, v8:8539
Change-Id: I6bcaea5060d8c481d7bae099f6db9f993cc30ee3
Reviewed-on: https://chromium-review.googlesource.com/c/1339119
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58443}
Refs: v8/v8@9365d09
Original commit message aac2f8c:
[coverage] Filter out singleton ranges that alias full ranges
Block coverage is based on a system of ranges that can either have
both a start and end position, or only a start position (so-called
singleton ranges). When formatting coverage information, singletons
are expanded until the end of the immediate full parent range. E.g.
in:
{0, 10} // Full range.
{5, -1} // Singleton range.
the singleton range is expanded to {5, 10}.
Singletons are produced mostly for continuation counters that track
whether we execute past a specific language construct.
Unfortunately, continuation counters can turn up in spots that confuse
our post-processing. For example:
if (true) { ... block1 ... } else { ... block2 ... }
If block1 produces a continuation counter, it could end up with the
same start position as the else-branch counter. Since we merge
identical blocks, the else-branch could incorrectly end up with an
execution count of one.
We need to avoid merging such cases. A full range should always take
precedence over a singleton range; a singleton range should never
expand to completely fill a full range. An additional post-processing
pass ensures this.
Bug: v8:8237
Change-Id: Idb3ec7b2feddc0585313810b9c8be1e9f4ec64bf
Reviewed-on: https://chromium-review.googlesource.com/c/1273095
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56531}
Refs: v8/v8@aac2f8c
deps: V8: backport 47d34a3
Original commit message:
Revert "[coverage] change block range to avoid ambiguity."
This reverts commit 471fef0469d04d7c487f3a08e81f3d77566a2f50.
Reason for revert: A more general fix incoming at https://crrev.com/c/1273095.
Original change's description:
> [coverage] change block range to avoid ambiguity.
>
> By moving the block range end to left of closing bracket,
> we can avoid ambiguity where an open-ended singleton range
> could be both interpreted as inside the parent range, or
> next to it.
>
> R=<U+200B>verwaest@chromium.org
>
> Bug: v8:8237
> Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
> Reviewed-on: https://chromium-review.googlesource.com/1254127
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56347}
TBR=yangguo@chromium.org,neis@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8237
Change-Id: I39310cf3c2f06a0d98ff314740aaeefbfffc0834
Reviewed-on: https://chromium-review.googlesource.com/c/1273096
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56513}
Refs: 47d34a317e
PR-URL: https://github.com/nodejs/node/pull/25429
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
46 lines
1.7 KiB
JavaScript
46 lines
1.7 KiB
JavaScript
// 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: --allow-natives-syntax --no-always-opt --opt
|
|
// Files: test/mjsunit/code-coverage-utils.js
|
|
|
|
%DebugToggleBlockCoverage(true);
|
|
|
|
TestCoverage(
|
|
"optimized and inlined functions",
|
|
`
|
|
function g() { if (true) nop(); } // 0000
|
|
function f() { g(); g(); } // 0050
|
|
f(); f(); %OptimizeFunctionOnNextCall(f); // 0100
|
|
f(); f(); f(); f(); f(); f(); // 0150
|
|
`,
|
|
[{"start":0,"end":199,"count":1},
|
|
{"start":0,"end":33,"count":4}, // TODO(jgruber): Invocation count is off.
|
|
{"start":25,"end":31,"count":16},
|
|
{"start":50,"end":76,"count":2}] // TODO(jgruber): Invocation count is off.
|
|
);
|
|
|
|
// This test is tricky: it requires a non-toplevel, optimized function.
|
|
// After initial collection, counts are cleared. Further invocation_counts
|
|
// are not collected for optimized functions, and on the next coverage
|
|
// collection we and up with an uncovered function with an uncovered parent
|
|
// but with non-trivial block coverage.
|
|
TestCoverage("Partial coverage collection",
|
|
`
|
|
!function() { // 0000
|
|
function f(x) { // 0050
|
|
if (x) { nop(); } else { nop(); } // 0100
|
|
} // 0150
|
|
f(true); f(true); // 0200
|
|
%OptimizeFunctionOnNextCall(f); // 0250
|
|
%DebugCollectCoverage(); // 0300
|
|
f(false); // 0350
|
|
}(); // 0400
|
|
`,
|
|
[{"start":52,"end":153,"count":0},
|
|
{"start":121,"end":137,"count":1}]
|
|
);
|
|
|
|
%DebugToggleBlockCoverage(false);
|