1. 31 May, 2019 1 commit
  2. 23 May, 2019 2 commits
  3. 22 May, 2019 1 commit
  4. 20 May, 2019 3 commits
  5. 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
  6. 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
  7. 09 Apr, 2019 1 commit
  8. 27 Feb, 2019 1 commit
  9. 26 Dec, 2018 1 commit
  10. 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
  11. 20 Dec, 2018 1 commit
  12. 17 Dec, 2018 1 commit
  13. 30 Nov, 2018 1 commit
  14. 28 Nov, 2018 1 commit
  15. 24 Nov, 2018 1 commit
  16. 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
  17. 02 Oct, 2018 1 commit
  18. 18 Jul, 2018 1 commit
  19. 04 Jul, 2018 1 commit
  20. 26 Jun, 2018 1 commit
  21. 04 Apr, 2018 1 commit
    • jgruber's avatar
      [coverage] Fix invalid coverage block transformation · e42ce200
      jgruber authored
      Before reporting coverage data, we attempt to reduce clutter by
      merging nested and consecutive ranges. Nested ranges are merged, if
      the child range has the same execution count as the parent range.
      Sibling ranges are merged, if one sibling begins where the other ends
      and execution counts are identical.
      
      This allowed an invalid transformation in which a range with an
      execution count of 1 would be merged into the parent change, but the
      sibling range with identical start and end points and a count of 0
      would remain, effectively deleting the covered range.
      
      For example:
      
      {start: 0, end: 10, count: 1},
      {start: 5, end:  8, count: 1},  // It's invalid to remove this.
      {start: 5, end:  8, count: 0}
      
      The fix is to separate the parent and sibling merge passes, and
      removing duplicate ranges in-between.
      
      Bug: chromium:827530
      Change-Id: Ic35eae1d4a106746570ce9cb412ed6710ef6da53
      Reviewed-on: https://chromium-review.googlesource.com/992114Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52352}
      e42ce200
  22. 16 Mar, 2018 1 commit
  23. 08 Dec, 2017 1 commit
  24. 17 Oct, 2017 1 commit
  25. 29 Sep, 2017 1 commit
  26. 25 Sep, 2017 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Fix (D)CHECK macros in src/{debug,inspector} · 8d38c15e
      Clemens Hammacher authored
      Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
      embedded comparison. This gives better error messages and also does the
      right comparison for signed/unsigned mismatches.
      
      This will allow us to reenable the readability/check cpplint check.
      
      R=yangguo@chromium.org
      
      Bug: v8:6837
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: I88e5afea1ad0fdf23a81b380e64ff356bbc20112
      Reviewed-on: https://chromium-review.googlesource.com/681374Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48138}
      8d38c15e
  27. 13 Sep, 2017 1 commit
  28. 11 Sep, 2017 2 commits
  29. 08 Sep, 2017 1 commit
  30. 05 Sep, 2017 1 commit
    • Juliana Franco's avatar
      Remove weak-list of optimized JS functions. · f0acede9
      Juliana Franco authored
      This CL removes the weak-list of JS functions from the context
      and all the code that iterares over it. This list was being used
      mainly during deoptimization (for code unlinking) and during
      garbage collection. Removing it will improve performance of
      programs that create many closures and trigger many scavenge GC
      cycles.
      
      No extra work is required during garbage collection. However,
      given that we no longer unlink code from JS functions during
      deoptimization, we leave it as it is, and on its next activation
      we check whether the mark_for_deoptimization bit of that code is
      set, and if it is, than we unlink it and jump to lazy compiled
      code. This check happens in the prologue of every code object.
       
      We needed to change/remove the cctests that used to check
      something on this list.
       
      Working in x64, ia32, arm64, arm, mips64 and mips. 
       
      
      Bug: v8:6637
      Change-Id: Ica99a12fd0351ae985e9a287918bf28caf6d2e24
      TBR: mstarzinger@chromium.org
      Reviewed-on: https://chromium-review.googlesource.com/647596
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47808}
      f0acede9
  31. 04 Sep, 2017 2 commits
    • Michael Achenbach's avatar
      Revert "Remove weak-list of optimized JS functions." · 36b50283
      Michael Achenbach authored
      This reverts commit 84c2dfce.
      
      Reason for revert:
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876
      
      Original change's description:
      > Remove weak-list of optimized JS functions.
      > 
      > This CL removes the weak-list of JS functions from the context
      > and all the code that iterares over it. This list was being used
      > mainly during deoptimization (for code unlinking) and during
      > garbage collection. Removing it will improve performance of
      > programs that create many closures and trigger many scavenge GC
      > cycles.
      > 
      > No extra work is required during garbage collection. However,
      > given that we no longer unlink code from JS functions during
      > deoptimization, we leave it as it is, and on its next activation
      > we check whether the mark_for_deoptimization bit of that code is
      > set, and if it is, than we unlink it and jump to lazy compiled
      > code. This check happens in the prologue of every code object.
      > 
      > We needed to change/remove the cctests that used to check
      > something on this list.
      > 
      > Working in x64, ia32, arm64, arm, mips64 and mips. 
      > 
      > Bug: v8:6637
      > Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
      > Reviewed-on: https://chromium-review.googlesource.com/600427
      > Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47790}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com
      
      Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6637
      Reviewed-on: https://chromium-review.googlesource.com/647540Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47792}
      36b50283
    • Juliana Franco's avatar
      Remove weak-list of optimized JS functions. · 84c2dfce
      Juliana Franco authored
      This CL removes the weak-list of JS functions from the context
      and all the code that iterares over it. This list was being used
      mainly during deoptimization (for code unlinking) and during
      garbage collection. Removing it will improve performance of
      programs that create many closures and trigger many scavenge GC
      cycles.
      
      No extra work is required during garbage collection. However,
      given that we no longer unlink code from JS functions during
      deoptimization, we leave it as it is, and on its next activation
      we check whether the mark_for_deoptimization bit of that code is
      set, and if it is, than we unlink it and jump to lazy compiled
      code. This check happens in the prologue of every code object.
      
      We needed to change/remove the cctests that used to check
      something on this list.
      
      Working in x64, ia32, arm64, arm, mips64 and mips. 
      
      Bug: v8:6637
      Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
      Reviewed-on: https://chromium-review.googlesource.com/600427
      Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47790}
      84c2dfce
  32. 28 Aug, 2017 1 commit
  33. 07 Aug, 2017 1 commit
  34. 02 Aug, 2017 1 commit