Skip to content

V
V8
Switch branch/tag
  1. 05 Sep, 2018 1 commit
    • Hai Dang's avatar
      Reland "[interpreter] Add bytecode for leading array spreads." · 5f8a4272
      Hai Dang authored 
      This is a reland of 1c48d52b.

It turned out that IterableToList doesn't always behave according to
the ES operation with the same name. Specifically, it allows holey arrays
to take its fast path, which produces an output array with holes where
actually "undefined" elements should appear.

This CL changes the version of IterableToList that is used for spreads
(IterableToListWithSymbolLookup) such that holey arrays take the slow path.
It also includes tests for such situations.

Original change's description:
> [interpreter] Add bytecode for leading array spreads.
>
> This CL improves the performance of creating [...a, b] or [...a].
> If the array literal has a leading spread, this CL emits the bytecode
> [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
> is implemented by [IterableToListDefault] builtin to create the initial
> array for the leading spread. IterableToListDefault has a fast path to
> clone efficiently if the spread is an actual array.
>
> The bytecode generated is now shorter. Bytecode generation is refactored
> into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
> from this optimization also.
> For now, turbofan also lowers the bytecode to the builtin.
>
> The idiomatic use of [...a] to clone the array a now performs better
> than a simple for-loop, but still does not match the performance of slice.
>
> Bug: v8:7980
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
> Reviewed-on: https://chromium-review.googlesource.com/1181024
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Commit-Queue: Hai Dang <dhai@google.com>
> Cr-Commit-Position: refs/heads/master@{#55520}

Bug: v8:7980
Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1201882
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55639}
      5f8a4272
  3. 31 Aug, 2018 1 commit
    • Georg Neis's avatar
      Revert "[interpreter] Add bytecode for leading array spreads." · ef569028
      Georg Neis authored 
      This reverts commit 1c48d52b.

Reason for revert: Clusterfuzz found something.

Original change's description:
> [interpreter] Add bytecode for leading array spreads.
> 
> This CL improves the performance of creating [...a, b] or [...a].
> If the array literal has a leading spread, this CL emits the bytecode
> [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
> is implemented by [IterableToListDefault] builtin to create the initial
> array for the leading spread. IterableToListDefault has a fast path to
> clone efficiently if the spread is an actual array.
> 
> The bytecode generated is now shorter. Bytecode generation is refactored
> into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
> from this optimization also.
> For now, turbofan also lowers the bytecode to the builtin.
> 
> The idiomatic use of [...a] to clone the array a now performs better
> than a simple for-loop, but still does not match the performance of slice.
> 
> Bug: v8:7980
> 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
> Reviewed-on: https://chromium-review.googlesource.com/1181024
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Commit-Queue: Hai Dang <dhai@google.com>
> Cr-Commit-Position: refs/heads/master@{#55520}

TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com

Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7980
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1199303Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55544}
      ef569028
  5. 30 Aug, 2018 1 commit
    • Hai Dang's avatar
      [interpreter] Add bytecode for leading array spreads. · 1c48d52b
      Hai Dang authored 
      This CL improves the performance of creating [...a, b] or [...a].
If the array literal has a leading spread, this CL emits the bytecode
[CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
is implemented by [IterableToListDefault] builtin to create the initial
array for the leading spread. IterableToListDefault has a fast path to
clone efficiently if the spread is an actual array.

The bytecode generated is now shorter. Bytecode generation is refactored
into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
from this optimization also.
For now, turbofan also lowers the bytecode to the builtin.

The idiomatic use of [...a] to clone the array a now performs better
than a simple for-loop, but still does not match the performance of slice.

Bug: v8:7980

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
Reviewed-on: https://chromium-review.googlesource.com/1181024Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#55520}
      1c48d52b
  7. 17 Aug, 2018 1 commit
  9. 25 Apr, 2018 1 commit
    • Andreas Haas's avatar
      Reland: [refactoring] Remove the isolate from signatures of ExternalReferences · 2a3c2c73
      Andreas Haas authored 
      I missed one required change which was hidden behind an #if. The fix is in
the diff between Patch 1 and Patch 3.

Original message:
In this CL I remove the isolate from signatures of ExternalReference
accessor functions where the isolate is not used. The uses of the
isolate were already removed in previous CLs.

Changes:
* I split the ExternalReference list in external-reference.h into
those which need the isolate for initialization and those which do not.

* I removed the public constructors and replaced them by
  ExternalReference::Create(). The reason is to separate external
  creation more clearly from internal creation, because externally
  created ExternalReferences sometimes need redirection, whereas
  internally created ExternalReferences are just stored as they are.
  In addition, by removing the isolate from the signature of the
  public constructors, they suddenly exactly matched the interal
  constructor.

* Replace all uses of the public constructors with
  ExternalReference::Create().

* Remove the isolate from all call sites where necessary.


This is a step towards making WebAssembly compilation independent of
the isolate.

R=mstarzinger@chromium.org

Bug: v8:7570
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I750c162f5d58ed32e866722b0db920f8b9bd8057
Reviewed-on: https://chromium-review.googlesource.com/1026673Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52777}
      2a3c2c73
  11. 24 Apr, 2018 2 commits
    • Andreas Haas's avatar
      Revert "[refactoring] Remove the isolate from signatures of ExternalReferences" · 7bfed2ad
      Andreas Haas authored 
      This reverts commit 44ea425a.

Reason for revert: https://ci.chromium.org/buildbot/client.v8.ports/V8%20Arm%20-%20debug%20builder/13575

Original change's description:
> [refactoring] Remove the isolate from signatures of ExternalReferences
> 
> In this CL I remove the isolate from signatures of ExternalReference
> accessor functions where the isolate is not used. The uses of the
> isolate were already removed in previous CLs.
> 
> Changes:
> * I split the ExternalReference list in external-reference.h into
> those which need the isolate for initialization and those which do not.
> 
> * I removed the public constructors and replaced them by
>   ExternalReference::Create(). The reason is to separate external
>   creation more clearly from internal creation, because externally
>   created ExternalReferences sometimes need redirection, whereas
>   internally created ExternalReferences are just stored as they are.
>   In addition, by removing the isolate from the signature of the
>   public constructors, they suddenly exactly matched the interal
>   constructor.
> 
> * Replace all uses of the public constructors with
>   ExternalReference::Create().
> 
> * Remove the isolate from all call sites where necessary.
> 
> 
> This is a step towards making WebAssembly compilation independent of
> the isolate.
> 
> Bug: v8:7570
> R=​mstarzinger@chromium.org
> 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da
> Reviewed-on: https://chromium-review.googlesource.com/1018982
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52768}

TBR=mstarzinger@chromium.org,ahaas@chromium.org

Change-Id: I7c0d8d420f815cede23d550dee8942ac4d7791cc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7570
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1026570Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52769}
      7bfed2ad
    • Andreas Haas's avatar
      [refactoring] Remove the isolate from signatures of ExternalReferences · 44ea425a
      Andreas Haas authored 
      In this CL I remove the isolate from signatures of ExternalReference
accessor functions where the isolate is not used. The uses of the
isolate were already removed in previous CLs.

Changes:
* I split the ExternalReference list in external-reference.h into
those which need the isolate for initialization and those which do not.

* I removed the public constructors and replaced them by
  ExternalReference::Create(). The reason is to separate external
  creation more clearly from internal creation, because externally
  created ExternalReferences sometimes need redirection, whereas
  internally created ExternalReferences are just stored as they are.
  In addition, by removing the isolate from the signature of the
  public constructors, they suddenly exactly matched the interal
  constructor.

* Replace all uses of the public constructors with
  ExternalReference::Create().

* Remove the isolate from all call sites where necessary.


This is a step towards making WebAssembly compilation independent of
the isolate.

Bug: v8:7570
R=mstarzinger@chromium.org

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da
Reviewed-on: https://chromium-review.googlesource.com/1018982
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52768}
      44ea425a
  13. 17 Apr, 2018 1 commit
  15. 02 Mar, 2018 1 commit
  17. 13 Oct, 2017 1 commit
  19. 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
  21. 09 Jan, 2017 1 commit
  23. 30 Sep, 2016 1 commit
  25. 12 Sep, 2016 1 commit
  27. 11 Feb, 2016 3 commits
  29. 09 Feb, 2016 2 commits
  31. 22 Jan, 2016 1 commit
    • jarin's avatar
      Runtime call counters and timers. · 747bd6f2
      jarin authored 
      In d8, run with --runtime-call-stats and it will output the stats when d8 finishes.

In Chrome, run the following: (only on trusted code, this punches *massive* security hole into Chrome)

chrome --js-flags="--runtime-call-stats --allow-natives-syntax"

To get the stats in the console, just run

console.log(%GetAndResetRuntimeCallStats());

To output stats every second:

setInterval(function() { console.log(%GetAndResetRuntimeCallStats()); }, 1000)

Review URL: https://codereview.chromium.org/1615943002

Cr-Commit-Position: refs/heads/master@{#33462}
      747bd6f2
  33. 15 Jan, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Add ForInPrepare runtime function which returns a ObjectTriple. · 84f8a506
      rmcilroy authored 
      Adds a ForInPrepare Runtime function which returns a triple of
cache_type, cache_array and cache_length.

This requires adding support to CEntryStub to call runtime functions
which return a ObjectTriple - a struct containing three Object*
pointers. Also did some cleanup of the x64 CEntryStub to avoid
replicated code.

Replaces the interpreter's use of the ad-hock InterpreterForInPrepare
Runtime function with ForInPrepare in preparation for fixing deopt in
BytecodeGraphBuilder for ForIn (which will be done in a followup CL).

MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1576093004

Cr-Commit-Position: refs/heads/master@{#33334}
      84f8a506
  35. 02 Oct, 2015 5 commits
    • rmcilroy's avatar
      [Interpreter] Add CallRuntime support to the interpreter. · 75f6ad74
      rmcilroy authored 
      Adds support for calling runtime functions from the interpreter. Adds the
CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
and the arguments in sequential registers. Adds a InterpreterCEntry builtin
to enable the interpreter to enter C++ code based on the functionId.

Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
and groups all the interpreter builtins together.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1362383002

Cr-Commit-Position: refs/heads/master@{#31089}
      75f6ad74
    • rmcilroy's avatar
      Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset... · b4a2f656
      rmcilroy authored 
      Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset #8 id:220001 of https://codereview.chromium.org/1362383002/ )

Reason for revert:
Now breaking arm32 debug bot (worked locally even with --debug-code, so I'll need to figure out what's different on the bot)

Original issue's description:
> [Interpreter] Add CallRuntime support to the interpreter.
>
> Adds support for calling runtime functions from the interpreter. Adds the
> CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
> and the arguments in sequential registers. Adds a InterpreterCEntry builtin
> to enable the interpreter to enter C++ code based on the functionId.
>
> Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
> and groups all the interpreter builtins together.
>
> BUG=v8:4280
> LOG=N
>

TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280

Review URL: https://codereview.chromium.org/1379933003

Cr-Commit-Position: refs/heads/master@{#31078}
      b4a2f656
    • rmcilroy's avatar
      [Interpreter] Add CallRuntime support to the interpreter. · c991d8f3
      rmcilroy authored 
      Adds support for calling runtime functions from the interpreter. Adds the
CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
and the arguments in sequential registers. Adds a InterpreterCEntry builtin
to enable the interpreter to enter C++ code based on the functionId.

Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
and groups all the interpreter builtins together.

BUG=v8:4280
LOG=N

Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc
Cr-Commit-Position: refs/heads/master@{#31064}

Review URL: https://codereview.chromium.org/1362383002

Cr-Commit-Position: refs/heads/master@{#31076}
      c991d8f3
    • rmcilroy's avatar
      Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset... · 90f69d16
      rmcilroy authored 
      Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset #6 id:180001 of https://codereview.chromium.org/1362383002/ )

Reason for revert:
Broke Arm64 bot (CEntry stub is trying to pop arguments off stack when argv_in_reg, so I need to fix this).

Original issue's description:
> [Interpreter] Add CallRuntime support to the interpreter.
>
> Adds support for calling runtime functions from the interpreter. Adds the
> CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
> and the arguments in sequential registers. Adds a InterpreterCEntry builtin
> to enable the interpreter to enter C++ code based on the functionId.
>
> Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
> and groups all the interpreter builtins together.
>
> BUG=v8:4280
> LOG=N
>
> Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc
> Cr-Commit-Position: refs/heads/master@{#31064}

TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280

Review URL: https://codereview.chromium.org/1387543002

Cr-Commit-Position: refs/heads/master@{#31066}
      90f69d16
    • rmcilroy's avatar
      [Interpreter] Add CallRuntime support to the interpreter. · 40e8424b
      rmcilroy authored 
      Adds support for calling runtime functions from the interpreter. Adds the
CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
and the arguments in sequential registers. Adds a InterpreterCEntry builtin
to enable the interpreter to enter C++ code based on the functionId.

Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
and groups all the interpreter builtins together.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1362383002

Cr-Commit-Position: refs/heads/master@{#31064}
      40e8424b
  37. 26 Aug, 2015 1 commit
  39. 18 Aug, 2015 1 commit
  41. 17 Mar, 2015 1 commit
  43. 11 Mar, 2015 2 commits
  45. 06 Mar, 2015 3 commits
  47. 05 Mar, 2015 1 commit
  49. 21 Jan, 2015 1 commit
  51. 19 Jan, 2015 1 commit
    • ishell's avatar
      Massive renaming of PropertyType values and other implied stuff. · 33994b4a
      ishell authored 
      PropertyKind:
  DATA -> kData
  ACCESSOR -> kAccessor

PropertyType:
  FIELD -> DATA
  CONSTANT -> DATA_CONSTANT
  ACCESSOR_FIELD -> ACCESSOR
  CALLBACKS -> ACCESSOR_CONSTANT

PropertyLocation:
  IN_OBJECT -> kField
  IN_DESCRIPTOR -> kDescriptor

StoreMode:
  FORCE_IN_OBJECT -> FORCE_FIELD

FieldDescriptor -> DataDescriptor
ConstantDescriptor -> DataConstantDescriptor
CallbacksDescriptor -> AccessorConstantDescriptor

Review URL: https://codereview.chromium.org/856503002

Cr-Commit-Position: refs/heads/master@{#26146}
      33994b4a
  53. 19 Nov, 2014 1 commit
  55. 10 Oct, 2014 1 commit
  57. 07 Oct, 2014 1 commit