1. 26 Apr, 2018 1 commit
  2. 24 Apr, 2018 1 commit
  3. 19 Apr, 2018 1 commit
  4. 04 Apr, 2018 1 commit
  5. 15 Mar, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Teach TurboFan about the TypedArray constructor. · 0875778f
      Benedikt Meurer authored
      This introduces a new JSCreateTypedArray operator, backed by a dedicated
      CreateTypedArray builtin, and adds support to lowering new TypedArray
      calls to this operator. This way we avoid the overhead of going through
      the generic construct stub machinery for hot code. This not only
      recovers the performance regression on the typed array constructor
      benchmarks, but even improves slightly beyond what we had in 6.6.
      
      We might in the future try to fully inline the TypedArray constructor
      into optimized code for certain cases.
      
      Bug: chromium:820726, v8:7503, v8:7518
      Change-Id: Ied465924d5695db576d533792f1db68456b9b5ea
      Reviewed-on: https://chromium-review.googlesource.com/959010
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51973}
      0875778f
  6. 05 Mar, 2018 3 commits
    • Sigurd Schneider's avatar
      [cleanup] Add accessors for operators with handles · a233b082
      Sigurd Schneider authored
      Bug: v8:7517, v8:7310
      Change-Id: Ic9a1ac8f4a928e1d5d8f807a0875c7314a7777fb
      Reviewed-on: https://chromium-review.googlesource.com/946095
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51735}
      a233b082
    • Sigurd Schneider's avatar
      [cleanup] Add DCHECK to uses of OpParameter<int> · a74b2491
      Sigurd Schneider authored
      Bug: v8:7517, v8:7310
      Change-Id: I438bc933d51062bfbb9a419be9c5b67032707fdb
      Reviewed-on: https://chromium-review.googlesource.com/946090
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51726}
      a74b2491
    • 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
  7. 02 Mar, 2018 1 commit
  8. 26 Feb, 2018 2 commits
    • Benedikt Meurer's avatar
      [turbofan] Further harden the JSCreateClosure nodes. · 597852f8
      Benedikt Meurer authored
      The CreateClosureMode introduced with 2ece046c is still not 100%
      fail-safe and doesn't scale. What we really need instead, especially
      when we might start removing the SharedFunctionInfo::code field
      eventually, is to tell the JSCreateClosure node which code object to
      use. So instead of adding magic around it, let's just pass it to the
      node.
      
      Bug: v8:2206, v8:7253, v8:7310
      Change-Id: Iedb6ae468a763643617975f47d96854d1aeafbe9
      Reviewed-on: https://chromium-review.googlesource.com/937121Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51548}
      597852f8
    • Benedikt Meurer's avatar
      [turbofan] Introduce explicit CreateClosureMode. · 2ece046c
      Benedikt Meurer authored
      We use JSCreateClosure to also constructs closures for builtins, i.e.
      for the callbacks created by the Promise constructor. For these builtins
      we cannot set code to CompileLazy builtin, but need to use the code from
      the SharedFunctionInfo. The explicit mode tells the lowering what it
      should do (instead of relying on SharedFunctionInfo::native(), which is
      not the right bit).
      
      Bug: v8:2206, v8:7253, v8:7310
      Change-Id: Ic956814e137c57b36ebb5d7b4d964dde5ee51a0d
      Reviewed-on: https://chromium-review.googlesource.com/930964
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51547}
      2ece046c
  9. 23 Feb, 2018 4 commits
  10. 22 Feb, 2018 3 commits
  11. 20 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Optimize promise resolution. · be6d1292
      Benedikt Meurer authored
      This CL introduces new operators JSFulfillPromise and JSPromiseResolve,
      corresponding to the specification operations with the same name, and
      uses that to lower calls to Promise.resolve() builtin to JSPromiseResolve.
      
      We also optimize JSPromiseResolve and JSResolvePromise further based on
      information found about the value/resolution in the graph. This applies
      to both Promise.resolve() builtin calls and implicit resolve operations
      in async functions and async generators.
      
      On a very simple microbenchmark like
      
        console.time('resolve');
        for (let i = 0; i < 1e8; ++i) Promise.resolve({i});
        console.timeEnd('resolve');
      
      this CL reduces the execution time from around 3049ms to around 947ms,
      which is a pretty significant 3x improvement. On the wikipedia benchmark
      we observe an improvement around 2% with this CL.
      
      Bug: v8:7253
      Change-Id: Ic69086cdc1b724f35dbe83305795539c562ab817
      Reviewed-on: https://chromium-review.googlesource.com/913488Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51387}
      be6d1292
  12. 13 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Refactor the promise resolution and rejection logic. · c0412961
      Benedikt Meurer authored
      This introduces dedicated builtins
      
        - FulfillPromise,
        - RejectPromise, and
        - ResolvePromise,
      
      which perform the corresponding operations from the language
      specification, and removes the redundant entry points and the
      excessive inlining of these operations into other builtins. We
      also add the same logic on the C++ side, so that we don't need
      to go into JavaScript land when resolving/rejecting from the
      API.
      
      The C++ side has a complete implementation, including full support
      for the debugger and the current PromiseHook machinery. This is to
      avoid constantly crossing the boundary for those cases, and to also
      simplify the CSA side (and soon the TurboFan side), where we only
      do the fast-path and bail out to the runtime for the general handling.
      
      On top of this we introduce %_RejectPromise and %_ResolvePromise,
      which are entry points used by the bytecode and parser desugarings
      for async functions, and also used by the V8 Extras API. Thanks to
      this we can uniformly optimize these in TurboFan, where we have
      corresponding operators JSRejectPromise and JSResolvePromise, which
      currently just call into the builtins, but middle-term can be further
      optimized, i.e. to skip the "then" lookup for JSResolvePromise when
      we know something about the resolution.
      
      In TurboFan we can also already inline the default PromiseCapability
      [[Reject]] and [[Resolve]] functions, although this is not as effective
      as it can be right now, until we have inlining support for the Promise
      constructor (being worked on by petermarshall@ right now) and/or SFI
      based CALL_IC feedback.
      
      Overall this change is meant as a refactoring without significant
      performance impact anywhere; it seems to improve performance of
      simple async functions a bit, but otherwise is neutral.
      
      Bug: v8:7253
      Change-Id: Id0b979f9b2843560e38cd8df4b02627dad4b6d8c
      Reviewed-on: https://chromium-review.googlesource.com/911632Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51260}
      c0412961
  13. 08 Feb, 2018 1 commit
    • Adam Klein's avatar
      Revert "[builtins] Mega-revert to address the Dev blocker in crbug.com/808911." · 3916401e
      Adam Klein authored
      This reverts commit 14108f4c.
      
      Reason for revert: Not the culprit for Canary microtask crashes
      
      Original change's description:
      > [builtins] Mega-revert to address the Dev blocker in crbug.com/808911.
      > 
      > - Revert "[builtins] Save one word in contexts for Promise.all."
      >   This reverts commit 7632da06.
      > - Revert "[builtins] Also use the Promise#then protector for Promise#finally()."
      >   This reverts commit d4f072ce.
      > - Revert "[builtins] Don't mess with entered context for MicrotaskCallbacks."
      >   This reverts commit 6703dacd.
      > - Revert "[debugger] Properly deal with settled promises in catch prediction."
      >   This reverts commit 40dd0658.
      > - Revert "[builtins] Widen the fast-path for Promise builtins."
      >   This reverts commit db0556b7.
      > - Revert "[builtins] Unify PerformPromiseThen and optimize it with TurboFan."
      >   This reverts commit a582199c.
      > - Revert "[builtins] Remove obsolete PromiseBuiltinsAssembler::AppendPromiseCallback."
      >   This reverts commit 6bf88852.
      > - Revert "[builtins] Turn NewPromiseCapability into a proper builtin."
      >   This reverts commit 313b490d.
      > - Revert "[builtins] Inline InternalPromiseThen into it's only caller"
      >   This reverts commit f7bd6a2f.
      > - Revert "[builtins] Implement Promise#catch by really calling into Promise#then."
      >   This reverts commit b23b098f.
      > - Revert "[promise] Remove incorrect fast path"
      >   This reverts commit 0f6eafe8.
      > - Revert "[builtins] Squeeze JSPromise::result and JSPromise::reactions into a single field."
      >   This reverts commit 8a677a28.
      > - Revert "[builtins] Refactor promises to reduce GC overhead."
      >   This reverts commit 8e7737cb.
      > 
      > Tbr: hpayer@chromium.org
      > Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
      > Change-Id: I8c8ea5ed32ed62f6cd8b0d027a3707ddd891e5f1
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/906991
      > Commit-Queue: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#51158}
      
      Change-Id: I09d958cbebd635a325809072a290f2f53df8c5d4
      Tbr: adamk@chromium.org,yangguo@chromium.org,bmeurer@chromium.org
      Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/908988Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51181}
      3916401e
  14. 07 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Mega-revert to address the Dev blocker in crbug.com/808911. · 14108f4c
      Benedikt Meurer authored
      - Revert "[builtins] Save one word in contexts for Promise.all."
        This reverts commit 7632da06.
      - Revert "[builtins] Also use the Promise#then protector for Promise#finally()."
        This reverts commit d4f072ce.
      - Revert "[builtins] Don't mess with entered context for MicrotaskCallbacks."
        This reverts commit 6703dacd.
      - Revert "[debugger] Properly deal with settled promises in catch prediction."
        This reverts commit 40dd0658.
      - Revert "[builtins] Widen the fast-path for Promise builtins."
        This reverts commit db0556b7.
      - Revert "[builtins] Unify PerformPromiseThen and optimize it with TurboFan."
        This reverts commit a582199c.
      - Revert "[builtins] Remove obsolete PromiseBuiltinsAssembler::AppendPromiseCallback."
        This reverts commit 6bf88852.
      - Revert "[builtins] Turn NewPromiseCapability into a proper builtin."
        This reverts commit 313b490d.
      - Revert "[builtins] Inline InternalPromiseThen into it's only caller"
        This reverts commit f7bd6a2f.
      - Revert "[builtins] Implement Promise#catch by really calling into Promise#then."
        This reverts commit b23b098f.
      - Revert "[promise] Remove incorrect fast path"
        This reverts commit 0f6eafe8.
      - Revert "[builtins] Squeeze JSPromise::result and JSPromise::reactions into a single field."
        This reverts commit 8a677a28.
      - Revert "[builtins] Refactor promises to reduce GC overhead."
        This reverts commit 8e7737cb.
      
      Tbr: hpayer@chromium.org
      Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
      Change-Id: I8c8ea5ed32ed62f6cd8b0d027a3707ddd891e5f1
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/906991
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51158}
      14108f4c
  15. 02 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Unify PerformPromiseThen and optimize it with TurboFan. · a582199c
      Benedikt Meurer authored
      This creates a uniform PerformPromiseThen builtin, which performs the
      operation with the same name from the spec, except that it expects the
      handlers to be either undefined or callable already, since this is only
      relevant for a single callsite (namely Promise.prototype.then).
      
      Introduce a matching operator JSPerformPromiseThen into TurboFan, which
      represents this operation and removes the additional checks in case of
      Promise.prototype.then based on the information we can derived from the
      receiver maps.
      
      This yields a nice 20-25% improvement on Promise.prototype.then, as
      illustrated by the following micro-benchmark
      
      ```js
      const N = 1e7;
      function inc(x) { return x + 1; }
      function chain(promise) {
        return promise.then(inc).then(value => {
            if (value < N) chain(Promise.resolve(value));
          });
      }
      console.time('total');
      chain(Promise.resolve(0));
      setTimeout(console.timeEnd.bind(console, 'total'));
      ```
      
      which goes from around 1230ms to 930ms with this patch.
      
      Bug: v8:7253
      Change-Id: I5712a863acdbe7da3bb8e621887c7b952148c51a
      Reviewed-on: https://chromium-review.googlesource.com/899064Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51071}
      a582199c
  16. 24 Jan, 2018 2 commits
  17. 11 Jan, 2018 1 commit
  18. 19 Dec, 2017 1 commit
  19. 12 Dec, 2017 1 commit
  20. 08 Dec, 2017 1 commit
  21. 07 Dec, 2017 1 commit
  22. 29 Nov, 2017 1 commit
    • Georg Neis's avatar
      No longer desugar the exponentiation (**) operator. · b97567a9
      Georg Neis authored
      Prior to this change, the exponentiation operator was rewritten by the
      parser to a call of the Math.pow builtin. However, Math.pow does not
      accept BigInt arguments, while the exponentiation operator must accept
      them.
      
      This CL
      - removes the parser's special treatment of ** and **=, treating them
        like any other binary op instead.
      - adds a TFC builtin Exponentiate that does the right thing for
        all inputs.
      - adds interpreter bytecodes Exp and ExpSmi whose handlers call the
        Exponentiate builtin. For simplicity, they currently always collect
        kAny feedback.
      - adds a Turbofan operator JSExponentiate with a typed-lowering to
        the existing NumberPow and a generic-lowering to the Exponentiate
        builtin. There is currently no speculative lowering.
      
      Note that exponentiation for BigInts is actually not implemented yet,
      so we can't yet test it.
      
      Bug: v8:6791
      Change-Id: Id90914c9c3fce310ce01e715c09eaa9f294f4f8a
      Reviewed-on: https://chromium-review.googlesource.com/785694Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49696}
      b97567a9
  23. 28 Nov, 2017 1 commit
  24. 23 Nov, 2017 1 commit
  25. 21 Nov, 2017 3 commits
  26. 27 Oct, 2017 1 commit
  27. 23 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce InstanceOfIC to collect rhs feedback. · bcee1406
      Benedikt Meurer authored
      This adds a new InstanceOfIC where the TestInstanceOf bytecode collects
      constant feedback about the right-hand side of instanceof operators,
      including both JSFunction and JSBoundFunction instances. TurboFan then
      uses the feedback to optimize instanceof in places where the right-hand
      side is not a known constant (known to TurboFan).
      
      This addresses the odd performance cliff that we see with instanceof in
      functions with multiple closures. It was discovered as one of the main
      bottlenecks on the uglify-es test in the web-tooling-benchmark. The
      uglify-es test (run in separation) is ~18% faster with this change.
      
      On the micro-benchmark in the tracking bug we go from
      
        instanceofSingleClosure_Const: 69 ms.
        instanceofSingleClosure_Class: 246 ms.
        instanceofMultiClosure: 246 ms.
        instanceofParameter: 246 ms.
      
      to
      
        instanceofSingleClosure_Const: 70 ms.
        instanceofSingleClosure_Class: 75 ms.
        instanceofMultiClosure: 76 ms.
        instanceofParameter: 73 ms.
      
      boosting performance by roughly 3.6x and thus effectively removing the
      performance cliff around instanceof.
      
      Bug: v8:6936, v8:6971
      Change-Id: Ib88dbb9eaef9cafa4a0e260fbbde73427a54046e
      Reviewed-on: https://chromium-review.googlesource.com/730686
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48820}
      bcee1406
  28. 20 Oct, 2017 1 commit
  29. 19 Oct, 2017 1 commit
    • Mike Stanton's avatar
      [Turbofan] Model JSToBoolean as a simplified operator · 78fc6668
      Mike Stanton authored
      Because the toboolean operator may lower to a builtin call (which is
      effectful in turbofan parlance after effect control linearization),
      it really should be encoded as a simplified operator, which can
      be optimized with respect for the effect chain in linearization.
      
      No new functionality here, rather a furniture rearrangement in
      the TurboFan node structure.
      
      Bug: v8:6929
      Change-Id: I371fd22941397d5c28d13bded2738161d8da8275
      Reviewed-on: https://chromium-review.googlesource.com/725721Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48727}
      78fc6668