Skip to content

V
V8
Switch branch/tag
  1. 01 Feb, 2018 1 commit
  3. 31 Jan, 2018 1 commit
  5. 18 Dec, 2017 1 commit
  7. 13 Dec, 2017 1 commit
  9. 08 Dec, 2017 2 commits
  11. 30 Nov, 2017 1 commit
  13. 18 Nov, 2017 1 commit
  15. 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
  17. 26 Oct, 2017 1 commit
  19. 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
  21. 19 Oct, 2017 1 commit
  23. 18 Oct, 2017 1 commit
  25. 17 Oct, 2017 1 commit
  27. 16 Oct, 2017 1 commit
  29. 13 Oct, 2017 1 commit
  31. 13 Sep, 2017 1 commit
  33. 08 Sep, 2017 1 commit
  35. 05 Sep, 2017 2 commits
  37. 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
  39. 31 Aug, 2017 1 commit
  41. 30 Aug, 2017 1 commit
  43. 28 Aug, 2017 1 commit
    • 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
  45. 02 Aug, 2017 1 commit
  47. 31 Jul, 2017 1 commit
  49. 27 Jul, 2017 1 commit
  51. 25 Jul, 2017 1 commit
  53. 17 Jul, 2017 1 commit
    • Leszek Swirski's avatar
      Revert "[runtime] Move profiler ticks from SFI to feedback vector" · 14c5c4fd
      Leszek Swirski authored 
      This reverts commit a2fcdc7c.

Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126)

Original change's description:
> [runtime] Move profiler ticks from SFI to feedback vector
> 
> Instead of counting profiler ticks on the shared function info (which is
> shared between native contexts), count them on the feedback vector
> (which is not). This allows us to continue pushing optimization
> decisions off the SFI, onto the feedback vector.
> 
> Note that a side-effect of this is that ICs don't have to walk the stack
> to reset profiler ticks, as they can access the feedback vector directly
> from their feedback nexus.
> 
> Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f
> Reviewed-on: https://chromium-review.googlesource.com/544888
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46411}

TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8
Reviewed-on: https://chromium-review.googlesource.com/574227
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46702}
      14c5c4fd
  55. 10 Jul, 2017 1 commit
  57. 05 Jul, 2017 1 commit
  59. 29 Jun, 2017 1 commit
  61. 22 Jun, 2017 1 commit
  63. 21 Jun, 2017 1 commit
  65. 19 Jun, 2017 1 commit
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector (reland) · 24b7026d
      Leszek Swirski authored 
      For interpreted functions, use the optimized code slot in the feedback
vector to store an optimization marker (optimize/in optimization queue)
rather than changing the JSFunction's code object. Then, adapt the
self-healing mechanism to also dispatch based on this optimization
marker. Similarly, replace SFI marking with optimization marker checks
in CompileLazy.

This allows JSFunctions to share optimization information (replacing
shared function marking) without leaking this information across native
contexts. Non I+TF functions (asm.js or --no-turbo) use a
CheckOptimizationMarker shim which generalises the old
CompileOptimized/InOptimizationQueue builtins and also checks the same
optimization marker as CompileLazy and InterpreterEntryTrampoline.

This is a reland of https://chromium-review.googlesource.com/c/509716

Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe
Reviewed-on: https://chromium-review.googlesource.com/535460Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45997}
      24b7026d
  67. 13 Jun, 2017 2 commits
    • Leszek Swirski's avatar
      Revert "[compiler] Drive optimizations with feedback vector" · 58978da6
      Leszek Swirski authored 
      This reverts commit e39c9e02.

Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561

Original change's description:
> [compiler] Drive optimizations with feedback vector
> 
> For interpreted functions, use the optimized code slot in the feedback vector
> to store an optimization marker (optimize/in optimization queue) rather than
> changing the JSFunction's code object. Then, adapt the self-healing mechanism
> to also dispatch based on this optimization marker. Similarly, replace SFI
> marking with optimization marker checks in CompileLazy.
> 
> This allows JSFunctions to share optimization information (replacing shared
> function marking) without leaking this information across native contexts. Non
> I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
> generalises the old CompileOptimized/InOptimizationQueue builtins and also
> checks the same optimization marker as CompileLazy and
> InterpreterEntryTrampoline.
> 
> Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
> Reviewed-on: https://chromium-review.googlesource.com/509716
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45901}

TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org
No-Presubmit: true
No-Tree-Checks: true
No-Try: true

Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94
Reviewed-on: https://chromium-review.googlesource.com/532916Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45903}
      58978da6
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector · e39c9e02
      Leszek Swirski authored 
      For interpreted functions, use the optimized code slot in the feedback vector
to store an optimization marker (optimize/in optimization queue) rather than
changing the JSFunction's code object. Then, adapt the self-healing mechanism
to also dispatch based on this optimization marker. Similarly, replace SFI
marking with optimization marker checks in CompileLazy.

This allows JSFunctions to share optimization information (replacing shared
function marking) without leaking this information across native contexts. Non
I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
generalises the old CompileOptimized/InOptimizationQueue builtins and also
checks the same optimization marker as CompileLazy and
InterpreterEntryTrampoline.

Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
Reviewed-on: https://chromium-review.googlesource.com/509716
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45901}
      e39c9e02
  69. 12 Jun, 2017 1 commit
  71. 17 May, 2017 1 commit
  73. 15 May, 2017 1 commit
    • Marja Hölttä's avatar
      Revert "[objects.h splitting] Move Map and related classes." · cc2c1144
      Marja Hölttä authored 
      This reverts commit 7be0159e.

Reason for revert: Broke node by generating a broken debug-support.cc

Original change's description:
> [objects.h splitting] Move Map and related classes.
> 
> BUG=v8:5402
> 
> Change-Id: I64fae0a0271eb0f1b71f4ec5d9bd5d22deb1cf59
> Reviewed-on: https://chromium-review.googlesource.com/502808
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45305}

TBR=marja@chromium.org,mstarzinger@chromium.org,jarin@chromium.org,ishell@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5402

Change-Id: Ifa65537447eb0a1ef947b9d0dae6f07a8b150968
Reviewed-on: https://chromium-review.googlesource.com/506011Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45307}
      cc2c1144