Skip to content

V
V8
Switch branch/tag
  1. 30 Apr, 2021 1 commit
  3. 11 Feb, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Generate accessors for struct-typed class fields · 6160a767
      Seth Brenith authored 
      Torque generates runtime accessor member functions for most class fields
that are defined in .tq files, but fields with struct types are
currently omitted. This change adds those accessors. As an example, if a
.tq file defines the following:

  struct InternalClassStructElement {
    a: Smi;
    b: Smi;
  }

  class InternalClassWithStructElements extends HeapObject {
    const count: Smi;
    entries[count]: InternalClassStructElement;
  }

Then the following accessors are generated to get and set each struct
field within the 'entries' field:

  inline int entries_a(int i) const;
  inline void set_entries_a(int i, int value);

  inline int entries_b(int i) const;
  inline void set_entries_b(int i, int value);

Bug: v8:7793
Change-Id: Ia40b5918e9d09f53ad8e78bc33f8629b8d6a79fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676926Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72662}
      6160a767
  5. 13 Jan, 2021 1 commit
  7. 09 Jan, 2021 1 commit
  9. 08 Jan, 2021 1 commit
  11. 20 Nov, 2020 2 commits
  13. 06 Jul, 2020 1 commit
  15. 03 Jun, 2020 1 commit
  17. 18 Feb, 2020 1 commit
    • Seth Brenith's avatar
      Assign CoverageInfo an instance type · 6ce65b96
      Seth Brenith authored 
      This allows CoverageInfo to be distinguished from other kinds of
FixedArray at runtime. I also updated it to use untagged data since it
only stores ints, since that seems like the generally right thing to do
(even though I doubt anybody allocates enough of these to notice the
reduced GC work).

Related Torque changes:
- Allow structs containing untagged data to be used as class fields.
  This requires classifying them into the tagged or untagged sections of
  the class layout, and checking that their alignment requirements are
  met when stored in a packed array.
- Generate a struct containing struct field offsets, so we can ensure
  that the layouts defined in Torque and C++ code match. Of course it
  would be nice to generate a lot more (indexed accessors, synchronized
  accessors, GC visitors, etc.), but we can't do it all at once.

Change-Id: I29e2a2afe37e4805cd80e3a84ef9edfe7ca7bb6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047399Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66318}
      6ce65b96
  19. 16 Oct, 2019 1 commit
    • Sigurd Schneider's avatar
      [coverage] Correctly report coverage for inline scripts · 0d7889d0
      Sigurd Schneider authored 
      This fixes a bug where coverage for the inline script
  <script>function foo() {}<script>
started to get deterministically reported as covered
after crrev.com/c/1771776, while before it, we most of
the time reported it as uncovered (depending on heap
order of SFIs). The correct result is to report `foo`
as uncovered as it is never called.

The problem arose from the fact that v8:9212 needed to
handle extra-wrappers around scripts correctly. Those
wrappers have the same source range as the wrapped
script and a call count of zero even if the wrapped
script is executed. To filter them out, we previously
determined nesting for identical source ranges by
ascending call count. However, in the script case above,
the script has call count one, while `foo` (which has
the same source range) has call count zero. In this
case, nesting is decreasing order of call counts.

This CL is a minimal change that sorts SFIs which are
top-level to the front, only then considers call counts
in descending order. This preserves the behavior that
node's extra wrappers are sorted to the front (and
then filtered out by existing logic), but also ensures
that for the example above, we report the script's
coverage before the coverage for `foo`.


Bug: v8:9857, v9:9212
Change-Id: Id224b0d8f12028b1f586ee5039e126bb5b8d8d36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863197Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64307}
      0d7889d0
  21. 30 Aug, 2019 1 commit
  23. 29 Aug, 2019 1 commit
    • Jakob Gruber's avatar
      [coverage] Extend block coverage tracing · 8e13de18
      Jakob Gruber authored 
      This extends --trace-block-coverage to output not only all raw coverage
slots, but also a detailed trace of all information that is generated by
coverage collection (i.e. after filtering and transforming collected
counts and ranges).

Example output:

Coverage for function='GetCoverage', SFI=0x3d23ea6dfb59,
has_nonempty_source_range=1, function_is_relevant=1
{start: 278, end: 441, count: 1}
{start: 357, end: 440, count: 0}

Bug: v8:6000,v8:9212
Change-Id: Ide09eb40999541df97409d0682a505ee0070b3a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771777
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63437}
      8e13de18
  25. 27 Aug, 2019 1 commit
  27. 08 Jul, 2019 1 commit
  29. 17 Jun, 2019 1 commit
  31. 31 May, 2019 1 commit
  33. 23 May, 2019 2 commits
  35. 22 May, 2019 1 commit
  37. 20 May, 2019 3 commits
  39. 16 May, 2019 1 commit
    • Jakob Gruber's avatar
      [coverage] Add dedicated FunctionLiteral counters · 3002ff44
      Jakob Gruber authored 
      Prior to this CL, call counts at function scope were taken from the
FeedbackVector::invocation_count field. This had two major drawbacks:
1. for generator functions, these count the number of resumptions
instead of the number of calls; and 2. the invocation count is not
maintained in optimized code.

The solution implemented here is to add a dedicated call counter at
function scope which is incremented exactly once each time the
function is called.

A minor complication is that our coverage output format expects
function-scope counts in the dedicated CoverageFunction object, and
not as a CoverageBlock. Thus function-scope block counts are initially
marked with magic positions, and later recognized and rewritten during
processing.

This CL thus fixes reported generator function call counts and enables
optimizations in block coverage modes (more to come in a follow-up).

Drive-by: Don't report functions with empty source ranges.

Bug: v8:6000,v8:9148,v8:9212
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: Idbe5edb35a595cf12b6649314738ac00efd173b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613996
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61574}
      3002ff44
  41. 10 May, 2019 1 commit
    • Mythri A's avatar
      [debug] Update code-coverage / type-profile to work with lazy feedback · 9e6b3565
      Mythri A authored 
      Precise code-coverage, collecting type profile and logging function events
need feedback vectors. This cl allocates feedback vector eagerly when any of
these features are required. When the code-coverage mode changes to anything
other than best case, this scans over the entire heap and allocates feedback
vectors for the required functions.

For best case code coverage we use interrupt budget field on the feedback
cell to infer if a function has executed. We still use the invocation count
on the feedback vector if feedback vector is available.

Bug: v8:8394
Change-Id: Ia0e656aaaa024d6d893a5badafc9a42ce36e9ea3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1601143Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61410}
      9e6b3565
  43. 09 Apr, 2019 1 commit
  45. 27 Feb, 2019 1 commit
  47. 26 Dec, 2018 1 commit
  49. 21 Dec, 2018 1 commit
    • Jakob Gruber's avatar
      [coverage] Rework continuation counter handling · 9365d090
      Jakob Gruber authored 
      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/1339119Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58443}
      9365d090
  51. 20 Dec, 2018 1 commit
  53. 17 Dec, 2018 1 commit
  55. 30 Nov, 2018 1 commit
  57. 28 Nov, 2018 1 commit
  59. 24 Nov, 2018 1 commit
  61. 10 Oct, 2018 2 commits
    • Jakob Gruber's avatar
      [coverage] Filter out singleton ranges that alias full ranges · aac2f8c9
      Jakob Gruber authored 
      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/1273095Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56531}
      aac2f8c9
    • Jakob Gruber's avatar
      Revert "[coverage] change block range to avoid ambiguity." · 47d34a31
      Jakob Gruber authored 
      This reverts commit 471fef04.

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=​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/1273096Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56513}
      47d34a31
  63. 02 Oct, 2018 1 commit
  65. 18 Jul, 2018 1 commit
  67. 04 Jul, 2018 1 commit
  69. 26 Jun, 2018 1 commit