1. 29 Jul, 2020 1 commit
  2. 20 Jul, 2020 1 commit
  3. 24 Feb, 2020 1 commit
  4. 20 Nov, 2019 1 commit
  5. 16 Oct, 2019 1 commit
  6. 15 May, 2019 1 commit
  7. 14 May, 2019 1 commit
  8. 18 Apr, 2019 1 commit
  9. 01 Apr, 2019 1 commit
  10. 19 Mar, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Significantly improve ConsString creation performance. · d6a60a0e
      Benedikt Meurer authored
      This change significantly improves the performance of string
      concatenation in optimized code for the case where the resulting string
      is represented as a ConsString. On the relevant test cases we go from
      
        serializeNaive: 10762 ms.
        serializeClever: 7813 ms.
        serializeConcat: 10271 ms.
      
      to
      
        serializeNaive: 10278 ms.
        serializeClever: 5533 ms.
        serializeConcat: 10310 ms.
      
      which represents a 30% improvement on the "clever" benchmark, which
      tests specifically the ConsString creation performance.
      
      This was accomplished via a couple of different steps, which are briefly
      outlined here:
      
        1. The empty_string gets its own map, so that we can easily recognize
           and handle it appropriately in the TurboFan type system. This
           allows us to express (and assert) that the inputs to NewConsString
           are non-empty strings, making sure that TurboFan no longer creates
           "crippled ConsStrings" with empty left or right hand sides.
        2. Further split the existing String types in TurboFan to be able to
           distinguish between OneByte and TwoByte strings on the type system
           level. This allows us to avoid having to dynamically lookup the
           resulting ConsString map in case of ConsString creation (i.e. when
           we know that both input strings are OneByte strings or at least
           one of the input strings is TwoByte).
        3. We also introduced more finegrained feedback for the Add bytecode
           in the interpreter, having it collect feedback about ConsStrings,
           specifically ConsOneByteString and ConsTwoByteString. This feedback
           can be used by TurboFan to only inline the relevant code for what
           was seen so far. This allows us to remove the Octane/Splay specific
           magic in JSTypedLowering to detect ConsString creation, and instead
           purely rely on the feedback of what was seen so far (also making it
           possible to change the semantics of NewConsString to be a low-level
           operator, which is only introduced in SimplifiedLowering by looking
           at the input types of StringConcat).
        4. On top of the before mentioned type and interpreter changes we added
           new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and
           CheckNonEmptyTwoByteString, which perform the appropriate (dynamic)
           checks.
      
      There are several more improvements that are possible based on this, but
      since the change was already quite big, we decided not to put everything
      into the first change, but do some follow up tweaks to the type system,
      and builtin optimizations later.
      
      Tbr: mstarzinger@chromium.org
      Bug: v8:8834, v8:8931, v8:8939, v8:8951
      Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Doc: https://bit.ly/fast-string-concatenation-in-javascript
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60318}
      d6a60a0e
  11. 02 Jan, 2019 1 commit
  12. 10 Dec, 2018 1 commit
    • Peter Marshall's avatar
      [runtime] Set arguments limit to FixedArray::kMaxLength · 4d2b197d
      Peter Marshall authored
      Right now, this is the limit implicitly imposed for spread/apply calls
      as to actually do a spread/apply call through CallVarargs, you need to
      pass a FixedArray with the args to be pushed.
      
      Likewise, turbofan can only materialize an arguments object with a
      backing store of length FixedArray::kMaxLength.
      
      The practical limit that users will actually hit is the stack - this
      change doesn't change that, it just documents what the actual limit is.
      
      This would actually allow an embedder/custom fork to increase stack
      size and still be able to make spread/apply calls with a large number
      of args.
      
      Change-Id: If5e66a61ed3f9df36031eb098646d48fc2ca2507
      Reviewed-on: https://chromium-review.googlesource.com/c/1367451Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58119}
      4d2b197d
  13. 30 Nov, 2018 1 commit
  14. 19 Sep, 2018 1 commit
  15. 18 Sep, 2018 1 commit
  16. 02 May, 2018 1 commit
  17. 28 Apr, 2018 1 commit
  18. 26 Apr, 2018 1 commit
  19. 05 Mar, 2018 1 commit
    • Benedikt Meurer's avatar
      [es2015] Refactor the JSArrayIterator. · 06ee127b
      Benedikt Meurer authored
      This changes the JSArrayIterator to always have only a single instance
      type, instead of the zoo of instance types that we had before, and
      which became less useful with the specification update to when "next"
      is loaded from the iterator now. This greatly simplifies the baseline
      implementation of the array iterator, which now only looks at the
      iterated object during %ArrayIteratorPrototype%.next invocations.
      
      In TurboFan we introduce a new JSCreateArrayIterator operator, that
      holds the IterationKind and get's the iterated object as input. When
      optimizing %ArrayIteratorPrototype%.next in the JSCallReducer, we
      check whether the receiver is a JSCreateArrayIterator, and if so,
      we try to infer maps for the iterated object from there. If we find
      any, we speculatively assume that these won't have changed during
      iteration (as we did before with the previous approach), and generate
      fast code for both JSArray and JSTypedArray iteration.
      
      Drive-by-fix: Drop the fast_array_iteration protector, it's not
      necessary anymore since we have the deoptimization guard bit in
      the JSCallReducer now.
      
      This addresses the performance cliff noticed in webpack 4. The minimal
      repro on the tracking bug goes from
      
        console.timeEnd: mono, 124.773000
        console.timeEnd: poly, 670.353000
      
      to
      
        console.timeEnd: mono, 118.709000
        console.timeEnd: poly, 141.393000
      
      so that's a 4.7x improvement.
      
      Also make presubmit happy by adding the missing #undef's.
      
      Bug: v8:7510, v7:7514
      Change-Id: I79a46bfa2cd0f0710e09365ef72519b1bbb667b5
      Reviewed-on: https://chromium-review.googlesource.com/946098Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51725}
      06ee127b
  20. 19 Feb, 2018 1 commit
  21. 17 Feb, 2018 2 commits
  22. 09 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [ic] Support negative indices for typed array OOB accesses. · 317fad95
      Benedikt Meurer authored
      Extend the current OOB support for typed arrays to also handle the
      negative integer indices in the fast-path. This is safe because in
      ECMAScript we never look up integer indexed properties (including
      negative indices) on typed arrays in the prototype chain.
      
      This reduces the performance cliff shown in the benchmark on the
      relevant bug from
      
        console.timeEnd: Runtime deopt, 596.185000
        console.timeEnd: Runtime deopt, 1444.289000
        console.timeEnd: Runtime deopt, 1445.191000
        console.timeEnd: Runtime deopt, 1443.008000
      
      to
      
        console.timeEnd: Runtime deopt, 590.017000
        console.timeEnd: Runtime deopt, 784.899000
        console.timeEnd: Runtime deopt, 792.428000
        console.timeEnd: Runtime deopt, 786.740000
      
      which corresponds to a 2x improvement overall. It's not for free,
      especially not in this benchmark, but the cliff isn't as bad as
      it was previously.
      
      Bug: v8:7027
      Change-Id: Icf8a7ee87bb7ebc54f82c1b9166fc5e78c12bc0e
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/911574Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51222}
      317fad95
  23. 17 Jan, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce NumberToString operator. · 02dbef14
      Benedikt Meurer authored
      This adds a new simplified operator NumberToString, which just lowers to
      a call to the NumberToString builtin, and hooks that up to the typed
      lowering (addressing a long-standing TODO).
      
      Drive-by-fix: Also remove the %NumberToString runtime entry, and just
      always use the %NumberToStringSkipCache entry from CSA, since we only
      go there if the cache lookup already failed.
      
      Bug: v8:5267, v8:7109
      Change-Id: I5ca698c98679653813088a404f1fd38903a73c0e
      Reviewed-on: https://chromium-review.googlesource.com/779099
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50636}
      02dbef14
  24. 13 Oct, 2017 1 commit
  25. 21 Aug, 2017 1 commit
  26. 09 Aug, 2017 2 commits
  27. 24 Jul, 2017 1 commit
  28. 22 Jul, 2017 1 commit
  29. 21 Jul, 2017 1 commit
  30. 12 Jun, 2017 1 commit
  31. 04 Jan, 2017 1 commit
  32. 08 Dec, 2016 1 commit
  33. 24 Nov, 2016 1 commit
  34. 10 Nov, 2016 1 commit
  35. 09 Nov, 2016 1 commit
  36. 17 Oct, 2016 1 commit
  37. 20 Sep, 2016 1 commit
  38. 05 Sep, 2016 1 commit