1. 28 Jul, 2020 1 commit
  2. 27 Jul, 2020 1 commit
  3. 06 Jul, 2020 1 commit
  4. 01 Jul, 2020 1 commit
  5. 25 Jun, 2020 1 commit
    • Mike Stanton's avatar
      [ic] Make FeedbackVector slot arrays immutable · 99576212
      Mike Stanton authored
      Currently the FeedbackVector uses arrays in slots that are polymorphic,
      usually in a <map, handler> tuple pattern. Helper functions try to
      re-use an existing array if it's already in place.
      
      For Concurrent TurboFan, it would be far better if these FixedArrays
      were immutable. We could then count on semantic correctness when
      harvesting their information from a background thread without locking.
      
      Additionally, the arrays should always be initialized fully before
      being set in place.
      
      Bug: v8:7790
      Change-Id: I81eae3bda48c2d0d8eea41d1bc9c62afb7e619d5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2264364Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68532}
      99576212
  6. 10 Jun, 2020 1 commit
  7. 08 Jun, 2020 2 commits
  8. 03 Jun, 2020 1 commit
  9. 02 Jun, 2020 1 commit
  10. 28 May, 2020 1 commit
    • Mythri A's avatar
      Hold on to FeedbackMetadata when allocating feedback vectors · 97ae1010
      Mythri A authored
      Allocating a new feedback vector happens in two steps: We create an
      empty structure and then initialize the array based on the
      FeedbackMetadata.When allocating a new feedback array we could trigger
      a GC which might flush the bytecode and associated feedback metadata.
      This shouldn't happen in normal cases, because we either allocate
      feedback vector after compilation or when we reach the expected budget.
      In both cases, the age of the feedback vector should be 0 and hence
      bytecode shouldn't be flushed. However, with debugger enabled we may
      allocate feedback vectors even when the bytecode array is old
      for example: when we enable precise invocation counters. This also
      causes issues in tests with --stress-flush-bytecode. In the stress mode
      we flush bytecode without considering the age. Holding on to the
      feedback metadata prevents crashes in such cases.
      
      Bug: v8:10560
      Change-Id: Ie806ff4102cb5fcf257c8683d5ca957853e38c05
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218066
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Auto-Submit: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68052}
      97ae1010
  11. 08 Apr, 2020 1 commit
  12. 02 Apr, 2020 1 commit
    • Mythri A's avatar
      [ic] Use the existing prototype validity cell when recomputing handlers · 800c294c
      Mythri A authored
      For keyed stores we recompute handlers based on the receiver maps
      we have seen. This is done so that we can transition to the most generic
      elements kind we have seen so far. When we recompute this handlers we
      get a new prototype validity cell and ignore the existing cell. This
      leads to incorrect behaviour if the cell was invalid. Recomputing the
      handler may be extra work which is not worth doing at this point. So
      we just reuse the existing validity cell and let the IC recompute the
      handler if we see the map again.
      
      Bug: chromium:1053939
      Change-Id: Ifc891d70f5a4b8b774238e12fb40e29b4d174e37
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122032
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66963}
      800c294c
  13. 16 Mar, 2020 1 commit
  14. 03 Mar, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Allow off-thread bytecode finalization · 455cb6c0
      Leszek Swirski authored
      Add the remaining missing templatizations to allow an initial wiring in
      of the off-thread factory into streaming compilation finalization.
      
      The off-thread finalization is behind a flag, disabled by default:
          --finalize-streaming-on-background
      
      When the flag is enabled, background tasks will perform perform the
      finalization during their background execution, and will release the
      parser and compilation jobs once they are no longer needed.
      
      The implementation is complete enough for performance testing, but not
      enough for launch. Notably, there is no support for:
      
        * Class boilerplates (the code is marked unreachable),
        * Exceptions during finalization, i.e. parse/compile warnings/errors,
        * Allocation sampling,
        * Logging,
        * Asm.js,
        * Parallel complication tasks
        * Forced source positions (for "NeedsDetailedOptimizedCodeLineInfo()")
      
      This patch also adds some tracing events for the various stages of the
      off-thread finalization (including the main-thread merge) for further
      performance improvements.
      
      Bug: chromium:1011762
      Change-Id: Ia44fa56975dd689f0d92c1543b294cdb063eb199
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066965
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66566}
      455cb6c0
  15. 29 Feb, 2020 1 commit
  16. 26 Nov, 2019 1 commit
    • Suraj Sharma's avatar
      Modify the DCheck to avoid failures. · 2174ba9f
      Suraj Sharma authored
      Now since we also encode KeyedAccessStoreMode information in the slow
      handler for some cases, the DCheck can result in failure.The Check can
      result in failures for other cases of StoreSlow. Removing the DCHECK
      altogether, now verifying the correctness of the behavior using the
      Kind Bits of the Handler in the method GetKeyedAccessStoreMode.
      
      
      Bug: chromium:1027025, chromium:1028085
      Change-Id: I59acedbb499930e67ae5999d4bfd0f040a34b46e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1929408Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Suraj Sharma <surshar@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65185}
      2174ba9f
  17. 20 Nov, 2019 2 commits
  18. 15 Nov, 2019 1 commit
  19. 12 Nov, 2019 2 commits
  20. 16 Oct, 2019 1 commit
  21. 02 Oct, 2019 1 commit
  22. 30 Sep, 2019 1 commit
  23. 12 Sep, 2019 1 commit
  24. 04 Sep, 2019 1 commit
    • Tobias Tebbi's avatar
      Revert "[compiler] improve inlining heuristics: call frequency per executed bytecodes" · eb443e1f
      Tobias Tebbi authored
      This reverts commit 352a154e.
      
      Reason for revert: https://crbug.com/999972
      
      Original change's description:
      > [compiler] improve inlining heuristics: call frequency per executed bytecodes
      > 
      > TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan
      > compile time including off-thread, while improving Octane scores by ~2%.
      > 
      > How things used to work:
      > 
      > There is a flag FLAG_min_inlining_frequency that limits inlining by
      > the callsite being sufficiently frequently executed. This call frequency
      > was measured relative to invocations of the parent (= the function we
      > originally optimize). At the same time, the limit was very low (0.15),
      > meaning we mostly relied on the total amount of inlined code
      > (FLAG_max_inlined_bytecode_size_cumulative) to limit inlining.
      > 
      > How things work now:
      > 
      > Instead of measuring call frequency relative to parent invocations, we
      > should have a measure that predicts how often the callsite in question
      > will be executed in the future. An obvious attempt at that would be to
      > measure how often the callsite was executed in absolute numbers in the
      > past. But depending on how fast feedback stabilizes, it can take more
      > or less time until we optimize a function. If we just take the absolute
      > call frequency up to the point in time when we optimize, we would
      > inline more for functions that stabilize slowly, which doesn't make
      > sense. So instead, we measure absolute call count per KB of executed
      > bytecodes of the parent function.
      > Since inlining big functions is more expensive, this threshold is
      > additionally scaled linearly with the bytecode-size of the inlinee.
      > The resulting formula is:
      > call_frequency >
      > FLAG_min_inlining_frequency *
      >   (bytecode.length() - FLAG_max_inlined_bytecode_size_small) /
      >   (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small)
      > 
      > The new threshold is chosen in a way that it effectively limits
      > inlining, which allows us to increase
      > FLAG_max_inlined_bytecode_size_cumulative without increasing inlining
      > in general.
      > 
      > The reduction in compile time (x64 build) of ~10% was observed in Octane,
      > ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark.
      > The hope is that this will reduce CPU-time in real-world situations
      > too.
      > The Octane improvements come from inlining more in places where it
      > matters.
      > 
      > Bug: v8:6682
      > 
      > Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63449}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org,mslekova@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:6682 chromium:999972
      Change-Id: Iffca63d4bef81afa0f66e34d35fb72f3b5baf517
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784281Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63554}
      eb443e1f
  25. 29 Aug, 2019 1 commit
    • Tobias Tebbi's avatar
      [compiler] improve inlining heuristics: call frequency per executed bytecodes · 352a154e
      Tobias Tebbi authored
      TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan
      compile time including off-thread, while improving Octane scores by ~2%.
      
      How things used to work:
      
      There is a flag FLAG_min_inlining_frequency that limits inlining by
      the callsite being sufficiently frequently executed. This call frequency
      was measured relative to invocations of the parent (= the function we
      originally optimize). At the same time, the limit was very low (0.15),
      meaning we mostly relied on the total amount of inlined code
      (FLAG_max_inlined_bytecode_size_cumulative) to limit inlining.
      
      How things work now:
      
      Instead of measuring call frequency relative to parent invocations, we
      should have a measure that predicts how often the callsite in question
      will be executed in the future. An obvious attempt at that would be to
      measure how often the callsite was executed in absolute numbers in the
      past. But depending on how fast feedback stabilizes, it can take more
      or less time until we optimize a function. If we just take the absolute
      call frequency up to the point in time when we optimize, we would
      inline more for functions that stabilize slowly, which doesn't make
      sense. So instead, we measure absolute call count per KB of executed
      bytecodes of the parent function.
      Since inlining big functions is more expensive, this threshold is
      additionally scaled linearly with the bytecode-size of the inlinee.
      The resulting formula is:
      call_frequency >
      FLAG_min_inlining_frequency *
        (bytecode.length() - FLAG_max_inlined_bytecode_size_small) /
        (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small)
      
      The new threshold is chosen in a way that it effectively limits
      inlining, which allows us to increase
      FLAG_max_inlined_bytecode_size_cumulative without increasing inlining
      in general.
      
      The reduction in compile time (x64 build) of ~10% was observed in Octane,
      ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark.
      The hope is that this will reduce CPU-time in real-world situations
      too.
      The Octane improvements come from inlining more in places where it
      matters.
      
      Bug: v8:6682
      
      Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63449}
      352a154e
  26. 19 Aug, 2019 4 commits
    • Georg Neis's avatar
      [turbofan] Brokerize ReduceJSStoreDataPropertyInLiteral · 8e065dbe
      Georg Neis authored
      Rewrite the reducer in terms of the ordinary keyed-store reducer and
      reuse the existing serializer machinery for that as well.
      
      Bug: v8:7790
      Change-Id: I5909739feee1d77dca1827166bad3d2a61561784
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760807Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63254}
      8e065dbe
    • Georg Neis's avatar
      Reland "[turbofan] Various serializer/broker improvements" · 4b1af9fc
      Georg Neis authored
      This is a reland of 29585a06 after
      removing an incorrect DCHECK.
      
      Original change's description:
      > [turbofan] Various serializer/broker improvements
      >
      > They are all somewhat entangled, sorry for the big CL.
      >
      > - Brokerize remaining feedback vector slots.
      > - Introduce Hints::SingleConstant helper.
      > - Introduce SerializationPolicy enum.
      > - Eliminate use of nullptr for megamorphic load/store ic feedback.
      >   Instead use the corresponding ProcessedFeedback with an empty list
      >   of maps or the like. new class MegamorphicFeedback.
      > - Separate processing of feedback from serialization. This eliminates
      >   code duplication.
      > - Be very careful when clearing hints not to overwrite hints that are
      >   being processed.
      > - Move AccessInfos out of NamedAccessFeedback. Always store them in
      >   property_access_infos_ map on broker. (This was actually unused
      >   before, somewhat by mistake.)
      > - Support map inference in concurrent inlining. Rewrite
      >   ElementAccessFeedback such that we can refine it with the set of
      >   inferred maps.
      >
      > TBR: mvstanton@chromium.org
      > Change-Id: I05e9eb250bdffc6dff29db01742550a86a41cb31
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752853
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63232}
      
      TBR: mvstanton@chromium.org
      Bug: v8:7790
      Change-Id: Ia4acd31b339a941ee065e1ae4835bb7b85d5685e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758319Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63241}
      4b1af9fc
    • Maya Lekova's avatar
      Revert "[turbofan] Various serializer/broker improvements" · 0645b26a
      Maya Lekova authored
      This reverts commit 29585a06.
      
      Reason for revert: Breaks GC stress bots - 
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24009
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/27281
      
      Original change's description:
      > [turbofan] Various serializer/broker improvements
      > 
      > They are all somewhat entangled, sorry for the big CL.
      > 
      > - Brokerize remaining feedback vector slots.
      > - Introduce Hints::SingleConstant helper.
      > - Introduce SerializationPolicy enum.
      > - Eliminate use of nullptr for megamorphic load/store ic feedback.
      >   Instead use the corresponding ProcessedFeedback with an empty list
      >   of maps or the like. new class MegamorphicFeedback.
      > - Separate processing of feedback from serialization. This eliminates
      >   code duplication.
      > - Be very careful when clearing hints not to overwrite hints that are
      >   being processed.
      > - Move AccessInfos out of NamedAccessFeedback. Always store them in
      >   property_access_infos_ map on broker. (This was actually unused
      >   before, somewhat by mistake.)
      > - Support map inference in concurrent inlining. Rewrite
      >   ElementAccessFeedback such that we can refine it with the set of
      >   inferred maps.
      > 
      > TBR: mvstanton@chromium.org
      > Change-Id: I05e9eb250bdffc6dff29db01742550a86a41cb31
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752853
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63232}
      
      TBR=mvstanton@chromium.org,neis@chromium.org
      
      Change-Id: I88625d92fddf993db63661666c59af05a47b2b58
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758314Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63237}
      0645b26a
    • Georg Neis's avatar
      [turbofan] Various serializer/broker improvements · 29585a06
      Georg Neis authored
      They are all somewhat entangled, sorry for the big CL.
      
      - Brokerize remaining feedback vector slots.
      - Introduce Hints::SingleConstant helper.
      - Introduce SerializationPolicy enum.
      - Eliminate use of nullptr for megamorphic load/store ic feedback.
        Instead use the corresponding ProcessedFeedback with an empty list
        of maps or the like. new class MegamorphicFeedback.
      - Separate processing of feedback from serialization. This eliminates
        code duplication.
      - Be very careful when clearing hints not to overwrite hints that are
        being processed.
      - Move AccessInfos out of NamedAccessFeedback. Always store them in
        property_access_infos_ map on broker. (This was actually unused
        before, somewhat by mistake.)
      - Support map inference in concurrent inlining. Rewrite
        ElementAccessFeedback such that we can refine it with the set of
        inferred maps.
      
      TBR: mvstanton@chromium.org
      Change-Id: I05e9eb250bdffc6dff29db01742550a86a41cb31
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752853
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63232}
      29585a06
  27. 05 Aug, 2019 1 commit
  28. 01 Aug, 2019 1 commit
  29. 08 Jul, 2019 1 commit
  30. 26 Jun, 2019 1 commit
  31. 25 Jun, 2019 2 commits
  32. 12 Jun, 2019 1 commit
  33. 31 May, 2019 1 commit
    • Benedikt Meurer's avatar
      [feedback-vector] Don't go MEGAMORPHIC due to dying handlers. · 40c68926
      Benedikt Meurer authored
      This fixes a problem where ICs for transitioning stores go MEGAMORPHIC
      if the transition target map dies in between invocations of the IC,
      which is totally possible, since we only hold on weakly to these
      transition targets (both from the FeedbackVectors and also from the
      TransitonArrays).
      
      The root problem here was an inconsistency in how the maps and handlers
      are being reported by the FeedbackVector. On the on hand side the method
      FeedbackVector::ExtractMaps() will report all receiver maps that are
      still present (i.e. which haven't died themselves), but then the other
      method FeedbackVector::FindHandlers() will only report handlers that are
      still alive (i.e. which in case of transition target maps being used as
      handlers haven't died yet). If the length of these lists don't match the
      IC chickens out and goes MEGAMORPHIC. But this is exactly the case with
      the transitioning stores, where there's no handler anymore, i.e. as can
      be seen in this simple example:
      
      ```
      // Flags: --expose-gc
      function C() { this.x = 1; }
      new C();
      new C();
      gc();     // map with the `C.x` property dies
      new C();  // now the STORE_IC in C goes MEGAMORPHIC
      ```
      
      So the problem is that we have these two methods that don't agree with
      each other. Now FeedbackVector::ExtractMaps() is also used by TurboFan
      and it even reports receiver maps for PREMONOMORPHIC state, which is
      different from the use case that the ICs need. So I replaced the
      FeedbackVector::FindHandlers() with a completely new method
      FeedbackVector::ExtractMapsAndHandlers(), which returns both the maps
      and handlers, exactly as the ICs need it. And only returns pairs for
      which both the receiver map and the handler are still alive.
      
      This fixes the odd problem that sometimes STORE_ICs going MEGAMORPHIC
      for no apparent reason. Due to the weakness of the transition target
      maps, they can still die and cause deoptimizations, but at least
      TurboFan will now be able to reoptimize again later with the new maps
      and still generate proper code.
      
      Bug: v8:9316
      Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      Change-Id: I74c8b60f792f310dc813f997e69efe9ad434296a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1637878
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61948}
      40c68926