1. 23 Nov, 2018 1 commit
  2. 20 Nov, 2018 1 commit
  3. 16 Nov, 2018 1 commit
  4. 15 Nov, 2018 1 commit
  5. 15 Oct, 2018 1 commit
  6. 12 Oct, 2018 1 commit
  7. 10 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Improve async function handling. · 0038e5f0
      Benedikt Meurer authored
      This change introduces new intrinsics used to desugar async functions
      in the Parser and the BytecodeGenerator, namely we introduce a new
      %_AsyncFunctionEnter intrinsic that constructs the generator object
      for the async function (and in the future will also create the outer
      promise for the async function). This generator object is internal
      and never escapes to user code, plus since async functions don't have
      a "prototype" property, we can just a single map here instead of tracking
      the prototype/initial_map on every async function. This saves one word
      per async function plus one initial_map per async function that was
      invoked at least once.
      
      We also introduce two new intrinsics %_AsyncFunctionReject, which
      rejects the outer promise with the caught exception, and another
      %_AsyncFunctionResolve, which resolves the outer promise with the
      right hand side of the `return` statement. These functions also perform
      the DevTools part of the job (aka popping from the promise stack and
      sending the debug event). This allows us to get rid of the implicit
      try-finally from async functions completely; because the finally
      block only called to the %AsyncFunctionPromiseRelease builtin, which
      was used to inform DevTools.
      
      In essence we now turn an async function like
      
      ```js
      async function f(x) { return await bar(x); }
      ```
      
      into something like this (in Parser and BytecodeGenerator respectively):
      
      ```
      function f(x) {
        .generator_object = %_AsyncFunctionEnter(.closure, this);
        .promise = %AsyncFunctionCreatePromise();
        try {
          .tmp = await bar(x);
          return %_AsyncFunctionResolve(.promise, .tmp);
        } catch (e) {
          return %_AsyncFunctionReject(.promise, e);
        }
      }
      ```
      
      Overall the bytecode for async functions gets significantly shorter
      already (and will get even shorter once we put the outer promise into
      the async function generator object). For example the bytecode for a
      simple async function
      
      ```js
      async function f(x) { return await x; }
      ```
      
      goes from 175 bytes to 110 bytes (a ~38% reduction in size), which
      is in particular due to the simplification around the try-finally
      removal.
      
      Overall this seems to improve the doxbee-async-es2017-native test by
      around 2-3%. On the test case mentioned in v8:8276 we go from
      1124ms to 441ms, which corresponds to a 60% reduction in total
      execution time!
      
      Tbr: marja@chromium.org
      Bug: v8:7253, v8:7522, v8:8276
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4
      Reviewed-on: https://chromium-review.googlesource.com/c/1269041
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56502}
      0038e5f0
  8. 09 Oct, 2018 1 commit
  9. 01 Oct, 2018 1 commit
  10. 21 Sep, 2018 1 commit
  11. 19 Sep, 2018 1 commit
  12. 07 Sep, 2018 1 commit
  13. 14 Aug, 2018 1 commit
  14. 23 Jul, 2018 1 commit
  15. 06 Jul, 2018 1 commit
  16. 19 Jun, 2018 1 commit
  17. 07 Jun, 2018 1 commit
  18. 19 Mar, 2018 1 commit
  19. 16 Mar, 2018 1 commit
  20. 02 Mar, 2018 1 commit
  21. 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
  22. 31 Jan, 2018 1 commit
  23. 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
  24. 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
  25. 30 Oct, 2017 2 commits
  26. 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
  27. 07 Sep, 2017 1 commit
  28. 05 Sep, 2017 1 commit
  29. 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
  30. 08 Aug, 2017 1 commit
  31. 19 Jul, 2017 1 commit
  32. 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
  33. 06 Jul, 2017 1 commit
  34. 05 Jul, 2017 2 commits
  35. 26 Jun, 2017 1 commit
  36. 19 Jun, 2017 1 commit
  37. 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
  38. 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