1. 19 Mar, 2018 1 commit
  2. 16 Mar, 2018 1 commit
  3. 02 Mar, 2018 1 commit
  4. 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
  5. 31 Jan, 2018 1 commit
  6. 03 Nov, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Generalized OOB support for KeyedLoadIC. · b7168573
      Benedikt Meurer authored
      This extends the support in TurboFan and the ICs for OOB loads to also
      apply to typed arrays and receivers whose prototype chain is protected
      by the "no elements" protector (aka the Array protector). TurboFan will
      generate code to materialize undefined instead when it sees a load that
      has the OOB bit set and add an appropriate code dependency on the global
      protector. For typed arrays it doesn't even need to check the global
      protector since elements are never looked up in the prototype chain
      for typed arrays.
      
      In the simple micro-benchmark from the bug we go from
      
        testInBounds: 103 ms.
        testOutOfBounds: 289 ms.
      
      to
      
        testInBounds: 103 ms.
        testOutOfBounds: 102 ms.
      
      which fixes the 3x slowdown and thus addresses the performance cliff. In
      general it's still beneficial to make sure that you don't access out of
      bounds, especially once we introduce a bounds check elimination pass to
      TurboFan.
      
      This also seems to improve the jQuery benchmark on the Speedometer test
      suite by like 1-2% on average. And the SixSpeed rest benchmarks go from
      
        rest-es5: 25 ms.
        rest-es6: 23 ms.
      
      to
      
        rest-es5: 6 ms.
        rest-es6: 4 ms.
      
      so a solid 5.7x improvement there.
      
      Bug: v8:6936, v8:7014, v8:7027
      Change-Id: Ie99699c69cc40057512e72fd40ae28107216c423
      Reviewed-on: https://chromium-review.googlesource.com/750089
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49095}
      b7168573
  7. 31 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [ic] Add OOB support to KeyedLoadIC. · 6dc35ab4
      Benedikt Meurer authored
      This adds support to the KeyedLoadIC to ignore out of bounds accesses
      for Strings and return undefined instead. We add a dedicated bit to the
      Smi handler to encode the OOB state and have TurboFan generate appropriate
      code for that case as well. This is mostly useful when programs
      accidentially access past the length of a string, which was observed and
      fixed for example in Babel recently, see
      
        https://github.com/babel/babel/pull/6589
      
      for details. The idea is to also extend this mechanism to Arrays and
      maybe other receivers, as reading beyond the length is also often used
      in jQuery and other popular libraries.
      
      Note that this is considered a mitigation for a performance cliff and
      not a general optimization of OOB accesses. These should still be
      avoided and handled properly instead.
      
      This seems to further improve the babel test on the web-tooling-benchmark
      by around 1%, because the OOB access no longer turns the otherwise
      MONOMORPHIC access into MEGAMORPHIC state.
      
      Bug: v8:6936, v8:7014
      Change-Id: I9df03304e056d7001a65da8e9621119f8e9bb55b
      Reviewed-on: https://chromium-review.googlesource.com/744022
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49049}
      6dc35ab4
  8. 30 Oct, 2017 2 commits
  9. 20 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [ic] Ensure that we make progress on KeyedLoadIC polymorphic name. · d5c19aa9
      Benedikt Meurer authored
      In the special case of KeyedLoadIC, where the key that is passed in is a
      Name that is always the same we only checked for identity in both the
      stub and the TurboFan case, which works fine for symbols and internalized
      strings, but doesn't really work with non-internalized strings, where
      the identity check will fail, the runtime will internalize the string,
      and the IC will then see the original internalized string again and not
      progress in the feedback lattice. This leads to tricky deoptimization
      loops in TurboFan and constantly missing ICs.
      
      This adds fixes the stub to always try to internalize strings first
      when the identity check fails and then doing the check again. If the
      name is not found in the string table we miss, since in that case the
      string cannot match the previously recorded feedback name (which is
      always a unique name).
      
      In TurboFan we represent this checks with new CheckEqualsSymbol and
      CheckEqualsInternalizedString operators, which validate the previously
      recorded feedback, and the CheckEqualsInternalizedString operator does
      the attempt to internalize the input.
      
      Bug: v8:6936, v8:6948, v8:6969
      Change-Id: I3f3b4a587c67f00f7c4b60d239eb98a9626fe04a
      Reviewed-on: https://chromium-review.googlesource.com/730224Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48784}
      d5c19aa9
  10. 07 Sep, 2017 1 commit
  11. 05 Sep, 2017 1 commit
  12. 01 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Optimize fast enum cache driven for..in. · f1ec44e2
      Benedikt Meurer authored
      This CL adds support to optimize for..in in fast enum-cache mode to the
      same degree that it was optimized in Crankshaft, without adding the same
      deoptimization loop that Crankshaft had with missing enum cache indices.
      That means code like
      
        for (var k in o) {
          var v = o[k];
          // ...
        }
      
      and code like
      
        for (var k in o) {
          if (Object.prototype.hasOwnProperty.call(o, k)) {
            var v = o[k];
            // ...
          }
        }
      
      which follows the https://eslint.org/docs/rules/guard-for-in linter
      rule, can now utilize the enum cache indices if o has only fast
      properties on the receiver, which speeds up the access o[k]
      significantly and reduces the pollution of the global megamorphic
      stub cache.
      
      For example the micro-benchmark in the tracking bug v8:6702 now runs
      faster than ever before:
      
       forIn: 1516 ms.
       forInHasOwnProperty: 1674 ms.
       forInHasOwnPropertySafe: 1595 ms.
       forInSum: 2051 ms.
       forInSumSafe: 2215 ms.
      
      Compared to numbers from V8 5.8 which is the last version running with
      Crankshaft
      
       forIn: 1641 ms.
       forInHasOwnProperty: 1719 ms.
       forInHasOwnPropertySafe: 1802 ms.
       forInSum: 2226 ms.
       forInSumSafe: 2409 ms.
      
      and V8 6.0 which is the current stable version with TurboFan:
      
       forIn: 1713 ms.
       forInHasOwnProperty: 5417 ms.
       forInHasOwnPropertySafe: 5324 ms.
       forInSum: 7556 ms.
       forInSumSafe: 11067 ms.
      
      It also improves the throughput on the string-fasta benchmark by
      around 7-10%, and there seems to be a ~5% improvement on the
      Speedometer/React benchmark locally.
      
      For this to work, the ForInPrepare bytecode was split into
      ForInEnumerate and ForInPrepare, which is very similar to how it was
      handled in Fullcodegen initially. In TurboFan we introduce a new
      operator LoadFieldByIndex that does the dynamic property load.
      
      This also removes the CheckMapValue operator again in favor of
      just using LoadField, ReferenceEqual and CheckIf, which work
      automatically with the EscapeAnalysis and the
      BranchConditionElimination.
      
      Bug: v8:6702
      Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
      Reviewed-on: https://chromium-review.googlesource.com/645949
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47768}
      f1ec44e2
  13. 08 Aug, 2017 1 commit
  14. 19 Jul, 2017 1 commit
  15. 11 Jul, 2017 1 commit
    • Alexandre Talon's avatar
      [Turbofan] Enable reducers to report their name to make reducer tracing clearer · 7a75da34
      Alexandre Talon authored
      Each reducer now has a virtual reducer_name function, returning its name
      (the name of the class containing this reducer). This gets displayed when
      using the --trace_turbo_reduction flag. Also when using this flags more
      messages are displayed.
      
      Actually when a node is replaced in-place (which is called an update
      of the node), other reducers can still update it right after the
      in-place replacement. When a node is really replaced (not in-place),
      then we stop trying to apply reducers to it before we propagate the
      reduction through the relevant nodes.
      
      Before a message got printed only for the last reduction it went
      through. So in case a node was reduced in-place several times
      in a row, only the last update was printed, or none at all if after
      being reduced in-place it got reduced by being replaced by another
      node: only the non-in-place replacement was showed. 
      
      Now each time an in-place reduction is applied to a node, a message
      gets printed.
      
      Bug: 
      Change-Id: Id0f816fecd44c01d0253966c6decc4861be0c2fa
      Reviewed-on: https://chromium-review.googlesource.com/563365Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Alexandre Talon <alexandret@google.com>
      Cr-Commit-Position: refs/heads/master@{#46552}
      7a75da34
  16. 06 Jul, 2017 1 commit
  17. 05 Jul, 2017 2 commits
  18. 26 Jun, 2017 1 commit
  19. 19 Jun, 2017 1 commit
  20. 16 Jun, 2017 1 commit
    • jarin's avatar
      [turbofan] Refactor property access building. · 126451d3
      jarin authored
      This is in preparation for lowering monomorphic loads during graph building.
      
      This essentially moves the parts that will be shared to a separate class/file
      (proparty-access-builder.(cc|h)).
      
      I should say that we will not want to do accessor inlining during graph
      building because that would require us to create frame states
      (which is the thing we would like to avoid doing).
      
      Review-Url: https://codereview.chromium.org/2936673005
      Cr-Commit-Position: refs/heads/master@{#45973}
      126451d3
  21. 13 Jun, 2017 1 commit
    • bmeurer's avatar
      [builtins] Properly optimize Object.prototype.isPrototypeOf. · b11c557d
      bmeurer authored
      Port the baseline implementation of Object.prototype.isPrototypeOf to
      the CodeStubAssembler, sharing the existing prototype chain lookup logic
      with the instanceof / OrdinaryHasInstance implementation. Based on that,
      do the same in TurboFan, introducing a new JSHasInPrototypeChain
      operator, which encapsulates the central prototype chain walk logic.
      
      This speeds up Object.prototype.isPrototypeOf by more than a factor of
      four, so that the code
      
        A.prototype.isPrototypeOf(a)
      
      is now performance-wise on par with
      
        a instanceof A
      
      for the case where A is a regular constructor function and a is an
      instance of A.
      
      Since instanceof does more than just the fundamental prototype chain
      lookup, it was discovered in Node core that O.p.isPrototypeOf would
      be a more appropriate alternative for certain sanity checks, since
      it's less vulnerable to monkey-patching. In addition, the Object
      builtin would also avoid the performance-cliff associated with
      instanceof (due to the Symbol.hasInstance hook), as for example hit
      by https://github.com/nodejs/node/pull/13403#issuecomment-305915874.
      The main blocker was the missing performance of isPrototypeOf, since
      it was still a JS builtin backed by a runtime call.
      
      This CL also adds more test coverage for the
      Object.prototype.isPrototypeOf builtin, especially when called from
      optimized code.
      
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      BUG=v8:5269,v8:5989,v8:6483
      R=jgruber@chromium.org
      
      Review-Url: https://codereview.chromium.org/2934893002
      Cr-Commit-Position: refs/heads/master@{#45925}
      b11c557d
  22. 23 May, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Add support for inlining accessors into try-blocks. · 9dbafbd5
      bmeurer authored
      Previously the inlining of accessors into try-blocks (i.e. try/catch,
      try/finally, for-of, etc.) was disabled in JSNativeContextSpecialization,
      which prevented a couple of interesting optimizations, i.e. we end up
      with a LOAD_IC in optimized code for this simple example:
      
        class A { get x() { return 1; } }
        function foo(a) {
          try {
            return a.x;
          } catch (e) {
            return 0;
          }
        }
        foo(new A)
      
      This is now fixed and the accessors are properly rewired into the
      handler chain.
      
      BUG=v8:6278,v8:6344,v8:6424
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2902533003
      Cr-Commit-Position: refs/heads/master@{#45485}
      9dbafbd5
  23. 17 May, 2017 1 commit
  24. 15 May, 2017 2 commits
  25. 09 May, 2017 1 commit
  26. 19 Apr, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Constant-fold certain JSOrdinaryHasInstance nodes. · c9c7dd0d
      bmeurer authored
      Move JSOrdinaryHasInstance lowering to JSNativeContextSpecialization,
      which was previously mostly done in JSTypedLowering (for no reason).
      Add new logic to the lowering to constant-fold OrdinaryHasInstance
      checks when the map of the left-hand side and the "prototype" of the
      right-hand side is known. This address the performance issue with the
      (base) class constructors generated by Babel, i.e.:
      
        function _classCallCheck(instance, Constructor) {
          if (!(instance instanceof Constructor)) {
            throw new TypeError("Cannot call a class as a function");
          }
        }
      
        var C = function C() { _classCallCheck(this, C); };
      
      for
      
        class C {}
      
      Also ensure that a known constructor being used inside an instanceof
      get's a proper initial map on-demand.
      
      BUG=v8:6275
      R=mstarzinger@chromium.org
      
      Review-Url: https://codereview.chromium.org/2827013002
      Cr-Commit-Position: refs/heads/master@{#44727}
      c9c7dd0d
  27. 10 Apr, 2017 1 commit
  28. 08 Apr, 2017 1 commit
  29. 07 Apr, 2017 1 commit
  30. 28 Mar, 2017 1 commit
  31. 15 Mar, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Skip JSCallReducer and JSNativeContextSpecialization on asm.js. · 94b33165
      bmeurer authored
      For the old asm.js pipeline, there's no point in running either the
      JSCallReducer or the JSNativeContextSpecialization, as both will not
      kick in for any asm.js relevant code.
      
      So remove the kDeoptimizationEnabled flag from both of them and just
      run them on regular JavaScript only.
      
      Drive-by-fix: Slightly rearrange keyed access to String receivers in the
      JSNativeContextSpecialization::ReduceKeyedAccess method to access constant
      characters independent of the IC mode (as long as the constant index is
      within the range of the receiver).
      
      BUG=v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2743253002
      Cr-Commit-Position: refs/heads/master@{#43813}
      94b33165
  32. 24 Feb, 2017 1 commit
  33. 21 Feb, 2017 1 commit
  34. 20 Feb, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Unify NodeProperties::InferReceiverMaps. · fc331225
      bmeurer authored
      Unify the three different implementations of InferReceiverMaps, which
      were basically copy&paste with slightly different optimizations applied
      later into a single NodeProperties::InferReceiverMaps helper, which also
      returns a ZoneHandleSet of maps, rather than only a single map.
      
      BUG=v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2703133003
      Cr-Commit-Position: refs/heads/master@{#43318}
      fc331225
  35. 17 Feb, 2017 1 commit
  36. 07 Feb, 2017 2 commits