1. 06 Jul, 2022 1 commit
  2. 13 Sep, 2019 1 commit
  3. 23 May, 2019 2 commits
  4. 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
  5. 27 Feb, 2019 1 commit
  6. 12 Oct, 2018 1 commit
  7. 18 Sep, 2018 1 commit
  8. 11 Sep, 2017 2 commits
  9. 08 Sep, 2017 1 commit
  10. 23 Jun, 2017 1 commit
    • jgruber's avatar
      [coverage] Expose block coverage through inspector · 1541f422
      jgruber authored
      This piggy-backs on top of existing precise and best-effort coverage to expose
      block coverage through the inspector protocol.
      
      Coverage collection now implicitly reports block-granularity coverage when
      available.  A new 'isBlockCoverage' property on Inspector's FunctionCoverage
      type specifies the granularity of reported coverage.
      
      For now, only count-based block coverage is supported, but binary block
      coverage should follow soon.
      
      Support is still gated behind the --block-coverage flag.
      
      Bug: v8:6000
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I9c4d64e1d2a098e66178b3a68dcee800de0081af
      Reviewed-on: https://chromium-review.googlesource.com/532975
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46157}
      1541f422
  11. 21 Jun, 2017 1 commit
    • jgruber's avatar
      [coverage] Improve source range precision · 63a7fa5a
      jgruber authored
      This CL improves reported source range precision in a couple of ways:
      
      Source ranges are now standardized to consist of an inclusive start
      index and an exclusive end index (similar to what's reported for
      functions). For example:
      
      0123456789  // Offset.
      { f(); }    // Block represented as range {0,8}.
      
      Duplicate singleton ranges (i.e. same start and end offsets) are now
      merged (this only becomes relevant once jump statement coverage is
      added). For example:
      
      for (.) break;  // Break- and loop continuation have same positions.
      
      SourceRangeScope incorrectly collected starting position
      (unconditionally) and end position (when no semi-colon was present).
      
      01234567890123  // Offset.
      for (.) break   // Loop body range is {8,13}, was {6,9}.
      
      Bug: v8:6000
      Change-Id: I62e7c70cc894a20f318330a2fbbcedc47da2b5db
      Reviewed-on: https://chromium-review.googlesource.com/541358
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46095}
      63a7fa5a
  12. 06 Jun, 2017 1 commit
    • jgruber's avatar
      [coverage] Block coverage with support for IfStatements · b4241540
      jgruber authored
      This CL implements general infrastructure for block coverage together with
      initial support for if-statements.
      
      Coverage output can be generated in lcov format by d8 as follows:
      
      $ d8 --block-coverage --lcov=$(echo ~/simple-if.lcov) ~/simple-if.js
      $ genhtml ~/simple-if.lcov -o ~/simple-if
      $ chrome ~/simple-if/index.html
      
      A high level overview of the implementation follows:
      
      The parser now collects source ranges unconditionally for relevant AST nodes.
      Memory overhead is very low and this seemed like the cleanest and simplest
      alternative.
      
      Bytecode generation uses these ranges to allocate coverage slots and insert
      IncBlockCounter instructions (e.g. at the beginning of then- and else blocks
      for if-statements). The slot-range mapping is generated here and passed on
      through CompilationInfo, and is later accessible through the
      SharedFunctionInfo.
      
      The IncBlockCounter bytecode fetches the slot-range mapping (called
      CoverageInfo) from the shared function info and simply increments the counter.
      We don't collect native-context-specific counts as they are irrelevant to our
      use-cases.
      
      Coverage information is finally generated on-demand through Coverage::Collect.
      The only current consumer is a d8 front-end with lcov-style output, but the
      short-term goal is to expose this through the inspector protocol.
      
      BUG=v8:6000
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Review-Url: https://codereview.chromium.org/2882973002
      Cr-Commit-Position: refs/heads/master@{#45737}
      b4241540
  13. 24 Mar, 2017 1 commit
  14. 23 Mar, 2017 3 commits
  15. 21 Mar, 2017 1 commit
  16. 22 Feb, 2017 1 commit
  17. 16 Feb, 2017 1 commit
  18. 15 Feb, 2017 1 commit
  19. 14 Feb, 2017 1 commit
  20. 10 Feb, 2017 1 commit
    • yangguo's avatar
      [debugger] add precise mode for code coverage. · 8422e25b
      yangguo authored
      Collecting precise invocation counts need to be explicitly
      enabled. Once enabled, we disable optimization (optimized
      code does not increment invocation count, and may inline
      callees), and make sure feedback vectors interesting for
      code coverage is not garbage-collected.
      
      R=hpayer@chromium.org, jgruber@chromium.org
      BUG=v8:5808
      
      Review-Url: https://codereview.chromium.org/2686063002
      Cr-Commit-Position: refs/heads/master@{#43082}
      8422e25b
  21. 09 Feb, 2017 1 commit
    • yangguo's avatar
      [debugger] implement per-function code coverage. · 058d7ab7
      yangguo authored
      Collect code coverage from the available invocation counts.
      The granularity is at function level, and invocation counts may
      be lost to GC.
      
      Coverage::Collect returns a std::vector of Coverage::ScriptData.
      Each ScriptData contains a script ID and a std::vector of
      Coverage::RangeEntry.
      Each RangeEntry consists of a end position and the invocation
      count. The start position is implicit from the end position of
      the previous RangeEntry, or 0 if it's the first RangeEntry.
      
      R=jgruber@chromium.org
      BUG=v8:5808
      
      Review-Url: https://codereview.chromium.org/2689493002
      Cr-Commit-Position: refs/heads/master@{#43072}
      058d7ab7