1. 08 Apr, 2020 1 commit
  2. 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
  3. 04 Mar, 2020 1 commit
  4. 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
  5. 17 Feb, 2020 1 commit
  6. 27 Nov, 2019 1 commit
    • Leszek Swirski's avatar
      [isolate] Make field getters use a const Isolate* · 42a56e03
      Leszek Swirski authored
      To indicate that the Isolate* in getters might not be a "real" isolate,
      but rather a calculated one from GetIsolateForPtrCompr only used for
      calculating the isolate root, make that function return a const Isolate*
      and change field getters, Object::IsFoo predicates, and related
      functions to all take a const Isolate* instead of an Isolate*
      
      With this change, we can slightly more confidently use Objects that are
      in OffThreadSpace, without having to worry too much about having an
      Isolate* floating around that could accidentally be used.
      
      This is a slight abuse of const semantics, but it allows implicit
      conversion from Isolate* arguments to the const Isolate* parameter.
      
      Bug: v8:7703
      Bug: chromium:1011762
      Change-Id: I54d4a65d2299477195f4d754cabe64ce34fdaa4c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939455
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65199}
      42a56e03
  7. 21 Nov, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] shape: define in-object properties properly · cfab6505
      Tobias Tebbi authored
      This introduces a new keyword "shape" in addition to "class",
      which allows the definition of a type that extends a JSObject
      subclass and specifies one or several maps with statically
      known in-object properties.
      Differences compared to normal classes:
      - Shapes are transient since they specify maps instead of
        instance types.
      - Shapes have a known size.
      - Fields of shapes are always in-object properties. In particular,
        this means that their offset is after kHeaderSize.
      - It's forbidden to inherited from shapes.
      - Since shapes usually specify NativeContext-dependent maps, it's
        not possible to write runtime type-checks for them. Thus this CL
        avoids mapping them to their own TNode type, as the CAST macro
        won't work properly. We had runtime-checks for some of them
        nevertheless, some of them scarily confusing like
        IsJSSloppyArgumentsObject, that actually just checked the instance
        type.
      
      Drive-by cleanups and simplifications:
      - Allow subclassing from non-abstract classes and remove
        @dirtyInstantiatedAbstractClass. This attribute stems from a mis-
        conception of how instance types work, and with this change it
        ceases to have semantic influence.
      - Replace the existing JSArgumentsObject subclasses into two shapes.
        JSArgumentsObjectWithLength had to be removed since shapes don't
        support subclassing.
      - Place kHeaderSize correctly for objects with indexed fields.
      
      Design doc:
      https://docs.google.com/document/d/1zPy2ZYfNFjeEuw6Mz3YJA-GaPGbdcSYam3SrS7ETzRU
      
      Bug: v8:8944
      
      Change-Id: Iabf185ccd27d0900e0890539a7fe9eaa8bf2d50e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917140
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65108}
      cfab6505
  8. 15 Nov, 2019 1 commit
  9. 10 Oct, 2019 1 commit
  10. 08 Oct, 2019 1 commit
  11. 02 Oct, 2019 1 commit
  12. 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
  13. 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
  14. 08 Jul, 2019 2 commits
  15. 26 Jun, 2019 2 commits
  16. 25 Jun, 2019 2 commits
  17. 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
  18. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  19. 24 May, 2019 1 commit
  20. 23 May, 2019 3 commits
  21. 20 May, 2019 3 commits
  22. 25 Apr, 2019 1 commit
  23. 10 Apr, 2019 3 commits
  24. 04 Apr, 2019 1 commit
  25. 25 Mar, 2019 2 commits
  26. 12 Mar, 2019 1 commit
  27. 11 Mar, 2019 1 commit
  28. 01 Mar, 2019 1 commit
    • Matt Gardner's avatar
      Reland "Optimize `in` operator" · 803ad324
      Matt Gardner authored
      The original was reverted for breaking webkit layout tests:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270
      
      It also caused the following clusterfuzz failures:
      
      chromium:935832
      This was a correctness bug due to not properly handling the case of arrays with prototypes other
      than Array.prototype. Accesses that were TheHole were not being handled property, both in bounds
      holes in holey arrays and out of bounds on either holey or packed arrays. Handling was incorrect
      both in access-assembler and in Turbofan.
      
      chromium:935932
      This bug was that there was no handling for Has checks on the global object. Turbofan was emitting
      code for a store (the 'else' condition on 'access_mode == AccessMode::kLoad'). It hit a DCHECK in
      debug builds but in release could show up in different places. This is the bug that caused the
      webkit layout test failure that led to the revert.
      
      Both bugs are fixed by in CL, and tests are added for those cases.
      
      Bug: v8:8733, chromium:935932, chromium:935832
      Change-Id: Iba0dfcfce6e15d2c0815a7670ece67bc13ba1925
      Reviewed-on: https://chromium-review.googlesource.com/c/1493132Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Matt Gardner <magardn@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#59958}
      803ad324
  29. 26 Feb, 2019 1 commit
  30. 25 Feb, 2019 1 commit