Skip to content

V
V8
Switch branch/tag
  1. 22 Nov, 2018 1 commit
  3. 16 Oct, 2018 1 commit
  5. 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
  7. 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
  9. 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
  11. 24 Apr, 2018 1 commit
  13. 08 Feb, 2018 1 commit
    • Adam Klein's avatar
      Revert "[builtins] Mega-revert to address the Dev blocker in crbug.com/808911." · 3916401e
      Adam Klein authored 
      This reverts commit 14108f4c.

Reason for revert: Not the culprit for Canary microtask crashes

Original change's description:
> [builtins] Mega-revert to address the Dev blocker in crbug.com/808911.
> 
> - Revert "[builtins] Save one word in contexts for Promise.all."
>   This reverts commit 7632da06.
> - Revert "[builtins] Also use the Promise#then protector for Promise#finally()."
>   This reverts commit d4f072ce.
> - Revert "[builtins] Don't mess with entered context for MicrotaskCallbacks."
>   This reverts commit 6703dacd.
> - Revert "[debugger] Properly deal with settled promises in catch prediction."
>   This reverts commit 40dd0658.
> - Revert "[builtins] Widen the fast-path for Promise builtins."
>   This reverts commit db0556b7.
> - Revert "[builtins] Unify PerformPromiseThen and optimize it with TurboFan."
>   This reverts commit a582199c.
> - Revert "[builtins] Remove obsolete PromiseBuiltinsAssembler::AppendPromiseCallback."
>   This reverts commit 6bf88852.
> - Revert "[builtins] Turn NewPromiseCapability into a proper builtin."
>   This reverts commit 313b490d.
> - Revert "[builtins] Inline InternalPromiseThen into it's only caller"
>   This reverts commit f7bd6a2f.
> - Revert "[builtins] Implement Promise#catch by really calling into Promise#then."
>   This reverts commit b23b098f.
> - Revert "[promise] Remove incorrect fast path"
>   This reverts commit 0f6eafe8.
> - Revert "[builtins] Squeeze JSPromise::result and JSPromise::reactions into a single field."
>   This reverts commit 8a677a28.
> - Revert "[builtins] Refactor promises to reduce GC overhead."
>   This reverts commit 8e7737cb.
> 
> Tbr: hpayer@chromium.org
> Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
> Change-Id: I8c8ea5ed32ed62f6cd8b0d027a3707ddd891e5f1
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/906991
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Adam Klein <adamk@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51158}

Change-Id: I09d958cbebd635a325809072a290f2f53df8c5d4
Tbr: adamk@chromium.org,yangguo@chromium.org,bmeurer@chromium.org
Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/908988Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51181}
      3916401e
  15. 07 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Mega-revert to address the Dev blocker in crbug.com/808911. · 14108f4c
      Benedikt Meurer authored 
      - Revert "[builtins] Save one word in contexts for Promise.all."
  This reverts commit 7632da06.
- Revert "[builtins] Also use the Promise#then protector for Promise#finally()."
  This reverts commit d4f072ce.
- Revert "[builtins] Don't mess with entered context for MicrotaskCallbacks."
  This reverts commit 6703dacd.
- Revert "[debugger] Properly deal with settled promises in catch prediction."
  This reverts commit 40dd0658.
- Revert "[builtins] Widen the fast-path for Promise builtins."
  This reverts commit db0556b7.
- Revert "[builtins] Unify PerformPromiseThen and optimize it with TurboFan."
  This reverts commit a582199c.
- Revert "[builtins] Remove obsolete PromiseBuiltinsAssembler::AppendPromiseCallback."
  This reverts commit 6bf88852.
- Revert "[builtins] Turn NewPromiseCapability into a proper builtin."
  This reverts commit 313b490d.
- Revert "[builtins] Inline InternalPromiseThen into it's only caller"
  This reverts commit f7bd6a2f.
- Revert "[builtins] Implement Promise#catch by really calling into Promise#then."
  This reverts commit b23b098f.
- Revert "[promise] Remove incorrect fast path"
  This reverts commit 0f6eafe8.
- Revert "[builtins] Squeeze JSPromise::result and JSPromise::reactions into a single field."
  This reverts commit 8a677a28.
- Revert "[builtins] Refactor promises to reduce GC overhead."
  This reverts commit 8e7737cb.

Tbr: hpayer@chromium.org
Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
Change-Id: I8c8ea5ed32ed62f6cd8b0d027a3707ddd891e5f1
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/906991
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51158}
      14108f4c
  17. 31 Jan, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Refactor promises to reduce GC overhead. · 8e7737cb
      Benedikt Meurer authored 
      This implements the ideas outlined in the section "Microtask queue"
of the exploration document "Promise and async/await performance" (at
https://goo.gl/WHRar2), except that the microtask queue stays a linear
FixedArray for now, to avoid running into trouble with the parallel
scavenger. This way we can already save a significant amount of
allocations, thereby reducing the GC frequency quite a bit.

All items on the microtask queue are now proper structs that subclass
Microtask, i.e. we also wrap JSFunction and MicrotaskCallback jobs
into structs. We also consistently remember the context for every
microtask (except for MicrotaskCallback where we don't have a
context), and execute it later in exactly that context (as required
by the spec anyways for the Promise related jobs). Particularly
interesting is the PromiseReactionJobTask and its subclasses, since
they are designed to have the same size as the PromiseReaction. When
we resolve a JSPromise we just take the existing PromiseReaction
instances and morph them into PromiseFulfillReactionJobTask or
PromiseRejectReactionJobTask (depending whether you "Fulfill" or
"Reject"). That way the JSPromise class is now only 6 words instead
of 10 words.

Also the PromiseReaction and the reaction tasks can either carry a
JSPromise (for the fast native case) or a PromiseCapability (for the
generic case), which means we don't always pay the overhead of having
to also remember the "deferred resolve" and "deferred reject" handlers
that are only relevant for the generic case anyways.

It also fixes a spec violation where we called "then" before we actually
enqueued the PromiseResolveThenableJob, which is observably wrong.
Calling it later has the advantage that it should be fairly
straight-forward now to completely avoid it for native Promise
instances.

This seems to save around 10-20% on the various Promise benchmarks and
micro-benchmarks. We expect to gain even more as we're now able to
inline various operations into TurboFan optimized code easily.

Bug: v8:7253
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I893d24ca5bb046974b4f5826a8f6dd22f1210b6a
Reviewed-on: https://chromium-review.googlesource.com/892819
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50980}
      8e7737cb
  19. 19 Jan, 2018 1 commit
  21. 20 Oct, 2017 1 commit
    • Mathias Bynens's avatar
      [js] Remove CHECK_OBJECT_COERCIBLE for Array methods · 35b6aa38
      Mathias Bynens authored 
      The spec got rid of `CheckObjectCoercible` a while back, and so should
we. This change is not observable in most of the affected cases since
`ToObject` is up near the top of most Array method algorithms. An
example of an observable effect of this change occurs for the following
input:

    Array.prototype.sort.call(null, 1);

Behavior before applying the patch (incorrect message):

    TypeError: Array.prototype.sort called on null or undefined

Expected behavior:

    TypeError: The comparison function must be either a function or
               undefined

This patch removes `CheckObjectCoercible` and adds tests to ensure the
few observable cases are addressed correctly.

The patch also adds a missing `ToObject(this)` to
`Array.prototype.lastIndexOf` which would otherwise become observable
as a result of `CheckObjectCoercible` being removed.

BUG=v8:3577,v8:6921

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ia086095076c4bf4d8d58dab26bc28df02994ed01
Reviewed-on: https://chromium-review.googlesource.com/718577Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48800}
      35b6aa38
  23. 02 Aug, 2017 1 commit
  25. 20 Jul, 2017 1 commit
  27. 10 Jul, 2017 1 commit
  29. 25 Mar, 2017 1 commit
  31. 31 Jan, 2017 1 commit
    • jwolfe's avatar
      Enable --harmony-trailing-commas · ea96fdec
      jwolfe authored 
      Also updated some tests due to the change. The general pattern is when a
trailing comma is expected to cause a SyntaxError, an additional comma was
added.

BUG=v8:5051
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2638513002
Cr-Commit-Position: refs/heads/master@{#42826}
      ea96fdec
  33. 19 Jan, 2017 1 commit
  35. 22 Dec, 2016 1 commit
  37. 21 Dec, 2016 1 commit
  39. 20 Dec, 2016 2 commits
  41. 07 Dec, 2016 1 commit
    • jwolfe's avatar
      Change error messages for octal escape sequences · 089e4fd3
      jwolfe authored 
      When an octal escape sequence is in a string in strict mode:
- Octal literals are not allowed in strict mode.
+ Octal escape sequences are not allowed in strict mode.

When an octal escape sequence is in a template string:
- Octal literals are not allowed in template strings.
+ Octal escape sequences are not allowed in template strings.

BUG=v8:4973
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2551633002
Cr-Commit-Position: refs/heads/master@{#41560}
      089e4fd3
  43. 02 Dec, 2016 1 commit
    • mstarzinger's avatar
      [compiler] Make --debug-code the default in debug builds. · 651c1b86
      mstarzinger authored 
      This enables {FLAG_debug_code} by default in debug builds. The advantage
is that generated code contained within the snapshot will contain such
debug code. Before we would only get coverage for these pieces with the
no-snapshot builds, which have a meager coverage. One can still pass the
inverse --no-debug-code flag to ensure generated code remains readable
within debug builds as well.

R=machenbach@chromium.org

Review-Url: https://codereview.chromium.org/2528913002
Cr-Commit-Position: refs/heads/master@{#41451}
      651c1b86
  45. 24 Nov, 2016 1 commit
  47. 18 Nov, 2016 1 commit
    • marja's avatar
      Remove FLAG_min_preparse_length. · 4a5b7e32
      marja authored 
      It originates from the era where we used to run a separate preparse step
before parsing and store the function data. Now the usage of preparser
is something completely different, so this flag doesn't make sense any
more.

In addition, this way we get more test coverage for preparser (for small
scripts).

BUG=

Review-Url: https://codereview.chromium.org/2513563002
Cr-Commit-Position: refs/heads/master@{#41110}
      4a5b7e32
  49. 04 Nov, 2016 2 commits
  51. 15 Sep, 2016 1 commit
  53. 29 Aug, 2016 1 commit
    • bgeron's avatar
      [turbofan] Also inline into try blocks. · 791118fc
      bgeron authored 
      This removes test/webkit/fast/js/stack-overflow-arrity-catch.js, which tests that the stack overflows in a very particular way. It doesn't seem to test anything important, and only used to work because we didn't inline into try-blocks.

BUG=
R=jarin

Review-Url: https://codereview.chromium.org/2216353002
Cr-Commit-Position: refs/heads/master@{#38976}
      791118fc
  55. 17 Aug, 2016 1 commit
  57. 22 Jul, 2016 1 commit
    • jwolfe's avatar
      Adjust whitespace to make tests oblivious to --harmony-function-tostring · 3cfd80d6
      jwolfe authored 
      See discussion in https://codereview.chromium.org/2156303002/#msg8

With the new --harmony-function-tostring behavior, these tests would
fail without this change. This change makes the tests pass regardless
of whether or not --harmony-function-tostring is used.

All of these changes are simply inserting a space after the "function"
keyword to match the current function toString behavior. When
--harmony-function-tostring is enabled, the toString behavior matches
the spacing used in the function declaration. With the declaration
matching the current formatting, the toString behavior becomes
unaffected by --harmony-function-tostring.

BUG=v8:4958
LOG=n

Review-Url: https://codereview.chromium.org/2161413002
Cr-Commit-Position: refs/heads/master@{#37959}
      3cfd80d6
  59. 12 Jul, 2016 1 commit
  61. 08 Jul, 2016 1 commit
  63. 30 Jun, 2016 1 commit
  65. 27 May, 2016 1 commit
    • littledan's avatar
      Unship ES2015 for-in initializer restrictions · 7245dabd
      littledan authored 
      We now have data that 0.011% of websites use the pattern
  for (var i = 0 in j) { ... }
This pattern was banned by ES2015, with the idea to revisit if
it presents a web compatibility problem. Informally, after
the May 2016 TC39 meeting, the new data was discussed, and there
was interest in reversing the decision. Although the specification
is not yet updated, it seems likely to come soon.

This patch turns off the flag which bans that construct, reenabling
it. The change should prevent websites from breaking.

BUG=v8:4942

Review-Url: https://codereview.chromium.org/2011223003
Cr-Commit-Position: refs/heads/master@{#36562}
      7245dabd
  67. 28 Apr, 2016 1 commit
  69. 21 Apr, 2016 1 commit
  71. 04 Apr, 2016 1 commit
  73. 01 Apr, 2016 1 commit
    • littledan's avatar
      Revert of Remove RegExp.prototype.source getter compat workaround (patchset #2... · 31e806eb
      littledan authored 
      Revert of Remove RegExp.prototype.source getter compat workaround (patchset #2 id:20001 of https://codereview.chromium.org/1837843002/ )

Reason for revert:
TC39 decided that this compatibility fix should be standardized.

Original issue's description:
> Remove RegExp.prototype.source getter compat workaround
>
> The getter RegExp.prototype.source is specified in ES2015 to throw when
> called on a non-RegExp instance, such as RegExp.prototype. We had previously
> put in a compatibility workaround for all RegExp getters to make them
> throw on access specifically with RegExp.prototype as the receiver; however,
> we only have evidence that this is needed for properties other than source.
> This patch removes the compatibility workaround for get RegExp.prototype.source
> and gives it semantics precisely as per the ES2015 specification.
>
> R=adamk
> BUG=chromium:581577,v8:4827
> LOG=Y
>
> Committed: https://crrev.com/80803aa89e31839b8f73959776fa7e1923c6b461
> Cr-Commit-Position: refs/heads/master@{#35086}

R=adamk@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:581577,v8:4827
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#35180}
      31e806eb
  75. 28 Mar, 2016 1 commit
    • littledan's avatar
      Remove RegExp.prototype.source getter compat workaround · 80803aa8
      littledan authored 
      The getter RegExp.prototype.source is specified in ES2015 to throw when
called on a non-RegExp instance, such as RegExp.prototype. We had previously
put in a compatibility workaround for all RegExp getters to make them
throw on access specifically with RegExp.prototype as the receiver; however,
we only have evidence that this is needed for properties other than source.
This patch removes the compatibility workaround for get RegExp.prototype.source
and gives it semantics precisely as per the ES2015 specification.

R=adamk
BUG=chromium:581577,v8:4827
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#35086}
      80803aa8