1. 29 Sep, 2017 2 commits
  2. 28 Sep, 2017 1 commit
  3. 25 Sep, 2017 2 commits
  4. 17 Sep, 2017 1 commit
  5. 16 Sep, 2017 1 commit
  6. 15 Sep, 2017 2 commits
  7. 14 Sep, 2017 3 commits
  8. 13 Sep, 2017 1 commit
  9. 12 Sep, 2017 2 commits
  10. 11 Sep, 2017 6 commits
  11. 08 Sep, 2017 2 commits
  12. 07 Sep, 2017 5 commits
  13. 06 Sep, 2017 3 commits
  14. 05 Sep, 2017 1 commit
    • Juliana Franco's avatar
      Remove weak-list of optimized JS functions. · f0acede9
      Juliana Franco authored
      This CL removes the weak-list of JS functions from the context
      and all the code that iterares over it. This list was being used
      mainly during deoptimization (for code unlinking) and during
      garbage collection. Removing it will improve performance of
      programs that create many closures and trigger many scavenge GC
      cycles.
      
      No extra work is required during garbage collection. However,
      given that we no longer unlink code from JS functions during
      deoptimization, we leave it as it is, and on its next activation
      we check whether the mark_for_deoptimization bit of that code is
      set, and if it is, than we unlink it and jump to lazy compiled
      code. This check happens in the prologue of every code object.
       
      We needed to change/remove the cctests that used to check
      something on this list.
       
      Working in x64, ia32, arm64, arm, mips64 and mips. 
       
      
      Bug: v8:6637
      Change-Id: Ica99a12fd0351ae985e9a287918bf28caf6d2e24
      TBR: mstarzinger@chromium.org
      Reviewed-on: https://chromium-review.googlesource.com/647596
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47808}
      f0acede9
  15. 04 Sep, 2017 2 commits
    • Michael Achenbach's avatar
      Revert "Remove weak-list of optimized JS functions." · 36b50283
      Michael Achenbach authored
      This reverts commit 84c2dfce.
      
      Reason for revert:
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876
      
      Original change's description:
      > Remove weak-list of optimized JS functions.
      > 
      > This CL removes the weak-list of JS functions from the context
      > and all the code that iterares over it. This list was being used
      > mainly during deoptimization (for code unlinking) and during
      > garbage collection. Removing it will improve performance of
      > programs that create many closures and trigger many scavenge GC
      > cycles.
      > 
      > No extra work is required during garbage collection. However,
      > given that we no longer unlink code from JS functions during
      > deoptimization, we leave it as it is, and on its next activation
      > we check whether the mark_for_deoptimization bit of that code is
      > set, and if it is, than we unlink it and jump to lazy compiled
      > code. This check happens in the prologue of every code object.
      > 
      > We needed to change/remove the cctests that used to check
      > something on this list.
      > 
      > Working in x64, ia32, arm64, arm, mips64 and mips. 
      > 
      > Bug: v8:6637
      > Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
      > Reviewed-on: https://chromium-review.googlesource.com/600427
      > Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47790}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com
      
      Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6637
      Reviewed-on: https://chromium-review.googlesource.com/647540Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47792}
      36b50283
    • Juliana Franco's avatar
      Remove weak-list of optimized JS functions. · 84c2dfce
      Juliana Franco authored
      This CL removes the weak-list of JS functions from the context
      and all the code that iterares over it. This list was being used
      mainly during deoptimization (for code unlinking) and during
      garbage collection. Removing it will improve performance of
      programs that create many closures and trigger many scavenge GC
      cycles.
      
      No extra work is required during garbage collection. However,
      given that we no longer unlink code from JS functions during
      deoptimization, we leave it as it is, and on its next activation
      we check whether the mark_for_deoptimization bit of that code is
      set, and if it is, than we unlink it and jump to lazy compiled
      code. This check happens in the prologue of every code object.
      
      We needed to change/remove the cctests that used to check
      something on this list.
      
      Working in x64, ia32, arm64, arm, mips64 and mips. 
      
      Bug: v8:6637
      Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
      Reviewed-on: https://chromium-review.googlesource.com/600427
      Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47790}
      84c2dfce
  16. 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
  17. 31 Aug, 2017 1 commit
  18. 29 Aug, 2017 1 commit
  19. 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