1. 16 Sep, 2017 1 commit
  2. 15 Sep, 2017 1 commit
  3. 14 Sep, 2017 1 commit
  4. 13 Sep, 2017 1 commit
  5. 12 Sep, 2017 1 commit
  6. 11 Sep, 2017 2 commits
  7. 08 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Drop obsolete %StringCharCodeAt intrinsic. · 62649c8e
      Benedikt Meurer authored
      The previous %StringCharCodeAt runtime entry (and the inlined intrinsic)
      are obsolete and not used anymore (except in dedicated tests for this
      runtime function), so remove it. And rename the %StringCharCodeAtRT
      function, which is actually used to %StringCharCodeAt instead to have
      a consistent naming scheme for runtime fallbacks.
      
      Bug: v8:5049
      Change-Id: I619429ef54f6efea61fc51ab9ed1d5cfe4417f99
      Reviewed-on: https://chromium-review.googlesource.com/657719
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47928}
      62649c8e
  8. 07 Sep, 2017 3 commits
  9. 06 Sep, 2017 1 commit
  10. 01 Sep, 2017 2 commits
    • 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
    • Michael Starzinger's avatar
      [turbofan] Support inline allocation of mapped outer arguments. · ed17bab8
      Michael Starzinger authored
      This adds support for lowering {JSCreateArguments} within outermost
      frames of type {CreateArgumentsType::kMappedArguments}. It will hence
      enable escape analysis to work with such objects and allow for further
      optimization.
      
      This also adds a new {NewMappedArgumentsElements} simplfied operator.
      Note that escape analysis support for this new operator will be done as
      a follow-up.
      
      R=tebbi@chromium.org
      
      Change-Id: I0e2fac25c654f796433f57b116964053b6b68635
      Reviewed-on: https://chromium-review.googlesource.com/641454
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47761}
      ed17bab8
  11. 28 Aug, 2017 2 commits
    • Jakob Gruber's avatar
      Revert "[csa] Refactor large-object handling in string allocation" · 3168a963
      Jakob Gruber authored
      This reverts commit f6d73509.
      
      Reason for revert: Perf regressions https://crbug.com/758126
      
      Original change's description:
      > [csa] Refactor large-object handling in string allocation
      > 
      > CSA::AllocateSeq{One,Two}ByteString used its own home-grown handling to
      > allocate very large strings. This CL refactors both methods to use
      > AllocationFlags::kAllowLargeObjectAllocation instead. Callers now need
      > to specify explicitly if large-object allocation is possible or not.
      > 
      > Bug: chromium:636391
      > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
      > Change-Id: I0b7ffb0b083f4e977cea42c500f8f2ee1c60519f
      > Reviewed-on: https://chromium-review.googlesource.com/625738
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47504}
      
      TBR=cbruni@chromium.org,jgruber@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:636391
      Change-Id: Iab88ce400f489a677df821d4053bd3678289ae2e
      Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/637392Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47639}
      3168a963
    • Benedikt Meurer's avatar
      [turbofan] Optimize O.p.hasOwnProperty inside for-in. · 06753c64
      Benedikt Meurer authored
      Optimize the common pattern
      
        for (var i in o) {
          if (Object.prototype.hasOwnProperty.call(o, i)) {
            // do something
          }
        }
      
      which is part of the guard-for-in style in ESLint (see the documentation
      at https://eslint.org/docs/rules/guard-for-in for details). This pattern
      also shows up in React and Ember applications quite a lot (and is tested
      by the appropriate Speedometer benchmarks, although not dominating those
      benchmarks, since they spent a lot of time in non-TurboFan'ed code).
      
      This improves the forInHasOwnProperty and forInHasOwnPropertySafe micro-
      benchmarks in v8:6702, which look like this
      
        function forInHasOwnProperty(o) {
          var result = 0;
          for (var i in o) {
            if (o.hasOwnProperty(i)) {
              result += 1;
            }
          }
          return result;
        }
      
        function forInHasOwnPropertySafe(o) {
          var result = 0;
          for (var i in o) {
            if (Object.prototype.hasOwnProperty.call(o, i)) {
              result += 1;
            }
          }
          return result;
        }
      
      by around 4x and allows for additional optimizations in the future, by
      also elimiating the megamorphic load when accessing the enumerated
      properties.
      
      This changes the interpreter ForInNext bytecode to collect more precise
      feedback about the for-in state, which now consists of three individual
      states: UNINITIALIZED, MEGAMORPHIC and GENERIC. The MEGAMORPHIC state
      means that the ForInNext has only seen objects with a usable enum cache
      thus far, whereas GENERIC means that we have seen some slow-mode for..in
      objects as well.
      
      R=jarin@chromium.org
      
      Bug: v8:6702
      Change-Id: Ibcd75ea9b58c3b4f9219f11bc37eb04a2b985604
      Reviewed-on: https://chromium-review.googlesource.com/636964
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47632}
      06753c64
  12. 23 Aug, 2017 1 commit
  13. 22 Aug, 2017 1 commit
    • jgruber's avatar
      [csa] Refactor large-object handling in string allocation · f6d73509
      jgruber authored
      CSA::AllocateSeq{One,Two}ByteString used its own home-grown handling to
      allocate very large strings. This CL refactors both methods to use
      AllocationFlags::kAllowLargeObjectAllocation instead. Callers now need
      to specify explicitly if large-object allocation is possible or not.
      
      Bug: chromium:636391
      Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
      Change-Id: I0b7ffb0b083f4e977cea42c500f8f2ee1c60519f
      Reviewed-on: https://chromium-review.googlesource.com/625738Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47504}
      f6d73509
  14. 21 Aug, 2017 1 commit
  15. 07 Aug, 2017 1 commit
  16. 01 Aug, 2017 1 commit
    • Benedikt Meurer's avatar
      [builtins] Speed-up Object.prototype.toString. · 31800120
      Benedikt Meurer authored
      The @@toStringTag lookup in Object.prototype.toString causes quite a
      lot of overhead and oftentimes dominates the builtin performance. These
      lookups are almost always negative, especially for primitive values,
      and Object.prototype.toString is often used to implement predicates
      (like in Node core or in AngularJS), so having a way to skip the
      negative lookup yields big performance gains.
      
      This CL introduces a "MayHaveInterestingSymbols" bit on every map,
      which says whether instances with this map may have an interesting
      symbol. Currently only @@toStringTag is considered an interesting
      symbol, but we can extend that in the future.
      
      In the Object.prototype.toString we can use the interesting symbols
      bit to do a quick check on the prototype chain to see if there are
      any maps that might have the @@toStringTag, and if not, we can just
      immediately return the result, which is very fast because it's derived
      from the instance type. This also avoids the ToObject conversions for
      primitive values, which is important, since this causes unnecessary
      GC traffic and in for example AngularJS, strings are also often probed
      via the Object.prototype.toString based predicates.
      
      This boosts Speedometer/AngularJS by over 3% and Speedometer overall
      by up to 1%. On the microbenchmark from the similar SpiderMonkey bug
      (https://bugzilla.mozilla.org/show_bug.cgi?id=1369042), we go from
      roughly 450ms to 70ms, which corresponds to a 6.5x improvement.
      
      ```
      function f() {
          var res = "";
          var a = [1, 2, 3];
          var toString = Object.prototype.toString;
          var t = new Date;
          for (var i = 0; i < 5000000; i++)
      	res = toString.call(a);
          print(new Date - t);
          return res;
      }
      f();
      ```
      
      The design document at https://goo.gl/e8CruQ has some additional
      data points.
      
      TBR=ulan@chromium.org
      
      Bug: v8:6654
      Change-Id: I31932cf41ecddad079d294e2c322a852af0ed244
      Reviewed-on: https://chromium-review.googlesource.com/593620
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47034}
      31800120
  17. 31 Jul, 2017 1 commit
  18. 25 Jul, 2017 1 commit
  19. 19 Jul, 2017 2 commits
  20. 11 Jul, 2017 1 commit
  21. 10 Jul, 2017 2 commits
    • Benedikt Meurer's avatar
      [builtins] Port Map and Set iterators to CodeStubAssembler. · 3b84cbfe
      Benedikt Meurer authored
      This is the next step towards faster Map and Set iteration. It
      introduces the appropriate instance types for Map and Set
      iterators (following the pattern for Array iterators) and migrates
      the following builtins to the CodeStubAssembler:
      
        - Set.prototype.entries
        - Set.prototype.values
        - Map.prototype.entries
        - Map.prototype.keys
        - Map.prototype.values
        - %SetIteratorPrototype%.next
        - %MapIteratorPrototype%.next
      
      This already provides a significant performance boost for regular
      for-of iteration of Sets and Maps, by a factor of 5-10 depending
      on the input. The final step will be to inline some fast-paths
      into TurboFan.
      
      Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
      intrinsics and runtime functions.
      
      TBR=jgruber@chromium.org
      
      Bug: v8:6344, v8:6571, chromium:740122
      Change-Id: I3ab0ee49e2afe8d4295707a5ecbd51adda621918
      Reviewed-on: https://chromium-review.googlesource.com/563626
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46497}
      3b84cbfe
    • Michael Achenbach's avatar
      Revert "[builtins] Port Map and Set iterators to CodeStubAssembler." · 5a6e24e9
      Michael Achenbach authored
      This reverts commit 3f22832b.
      
      Reason for revert: Layout tests:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16849
      
      Original change's description:
      > [builtins] Port Map and Set iterators to CodeStubAssembler.
      > 
      > This is the next step towards faster Map and Set iteration. It
      > introduces the appropriate instance types for Map and Set
      > iterators (following the pattern for Array iterators) and migrates
      > the following builtins to the CodeStubAssembler:
      > 
      >   - Set.prototype.entries
      >   - Set.prototype.values
      >   - Map.prototype.entries
      >   - Map.prototype.keys
      >   - Map.prototype.values
      >   - %SetIteratorPrototype%.next
      >   - %MapIteratorPrototype%.next
      > 
      > This already provides a significant performance boost for regular
      > for-of iteration of Sets and Maps, by a factor of 5-10 depending
      > on the input. The final step will be to inline some fast-paths
      > into TurboFan.
      > 
      > Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
      > intrinsics and runtime functions.
      > 
      > Bug: v8:6571, chromium:740122
      > Change-Id: Iad7a7dec643d8f8b5799327f89a351108ae856bf
      > Reviewed-on: https://chromium-review.googlesource.com/563399
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46492}
      
      TBR=jgruber@chromium.org,bmeurer@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:6571, chromium:740122
      Change-Id: Iadb48d72e3b85ec8ad880e50ab7912c5502caf07
      Reviewed-on: https://chromium-review.googlesource.com/564419Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46495}
      5a6e24e9
  22. 08 Jul, 2017 1 commit
    • Benedikt Meurer's avatar
      [builtins] Port Map and Set iterators to CodeStubAssembler. · 3f22832b
      Benedikt Meurer authored
      This is the next step towards faster Map and Set iteration. It
      introduces the appropriate instance types for Map and Set
      iterators (following the pattern for Array iterators) and migrates
      the following builtins to the CodeStubAssembler:
      
        - Set.prototype.entries
        - Set.prototype.values
        - Map.prototype.entries
        - Map.prototype.keys
        - Map.prototype.values
        - %SetIteratorPrototype%.next
        - %MapIteratorPrototype%.next
      
      This already provides a significant performance boost for regular
      for-of iteration of Sets and Maps, by a factor of 5-10 depending
      on the input. The final step will be to inline some fast-paths
      into TurboFan.
      
      Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
      intrinsics and runtime functions.
      
      Bug: v8:6571, chromium:740122
      Change-Id: Iad7a7dec643d8f8b5799327f89a351108ae856bf
      Reviewed-on: https://chromium-review.googlesource.com/563399
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46492}
      3f22832b
  23. 07 Jul, 2017 1 commit
  24. 06 Jul, 2017 1 commit
  25. 29 Jun, 2017 1 commit
  26. 27 Jun, 2017 2 commits
  27. 14 Jun, 2017 1 commit
  28. 13 Jun, 2017 2 commits
    • 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
    • Sathya Gunasekaran's avatar
      [Collections] Move size, clear, forEach to C++ · 2c65b0be
      Sathya Gunasekaran authored
      Bug: v8:5717
      Change-Id: I0e900b46a314a272206798aab8af5ccbb7f91fd3
      Reviewed-on: https://chromium-review.googlesource.com/528315Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45907}
      2c65b0be
  29. 07 Jun, 2017 2 commits
  30. 06 Jun, 2017 1 commit