Skip to content

V
V8
Switch branch/tag
  1. 30 Nov, 2018 1 commit
    • Peter Marshall's avatar
      Revert "[runtime] Reduce spread/apply call max arguments" · ff0cf00c
      Peter Marshall authored 
      This reverts commit 4e3a17d0.

Reason for revert: Web compact issues, see crbug.com/910252

Original change's description:
> [runtime] Reduce spread/apply call max arguments
> 
> Bug: chromium:906043
> Change-Id: I308b29af0644c318d73926b27e65a94913c760c7
> Reviewed-on: https://chromium-review.googlesource.com/c/1346115
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57731}

TBR=jarin@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org

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

Bug: chromium:906043
Change-Id: I240c1b55c10fd3e108e3c49f93ce1d9ca9c61780
Reviewed-on: https://chromium-review.googlesource.com/c/1356502Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57956}
      ff0cf00c
  3. 23 Nov, 2018 1 commit
    • Toon Verwaest's avatar
      [parser] Cleanup pattern classification · 2e052332
      Toon Verwaest authored 
      This changes the split from AssignmentPattern and BindingPattern to Pattern and
BindingPattern. Pattern collects all errors that are invalid in both assignment
and binding pattern contexts. Binding pattern additionally collects errors for
binding pattern contexts (property access isn't a valid target). The
distinction is piggybacked on to distinguish assignment vs binding pattern
errors since binding pattern verification will first throw the binding pattern
error.

Since we don't throw pattern error as binding pattern as well, this can mean
that a later binding pattern syntax error will show up before an early pattern
error. Since that just changes the message to another syntax violation, I think
that's fine.

Change-Id: Ib6a22c8d11c49eacc6667ae8ee5e98bababadd43
Reviewed-on: https://chromium-review.googlesource.com/c/1349273Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57774}
      2e052332
  5. 22 Nov, 2018 1 commit
  7. 19 Nov, 2018 1 commit
  9. 12 Nov, 2018 1 commit
  11. 08 Nov, 2018 2 commits
  13. 05 Nov, 2018 1 commit
  15. 18 Oct, 2018 1 commit
  17. 17 Oct, 2018 1 commit
  19. 16 Oct, 2018 1 commit
  21. 11 Oct, 2018 1 commit
  23. 04 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] First prototype of zero-cost async stack traces. · f537d778
      Benedikt Meurer authored 
      This introduces a new flag --async-stack-traces, which enables zero-cost
async stack traces. This enriches the non-standard Error.stack property
with async stack frames computed from walking up the promise chains and
collecting all the await suspension points along the way. In Error.stack
these async frames are marked with "async" to make it possible to
distinguish them from regular frames, for example:

```
Error: Some error message
    at bar (<anonymous>)
    at async foo (<anonymous>)
```

It's zero-cost because no additional information is collected during the
execution of the program, but only the information already present in the
promise chains is used to reconstruct an approximation of the async stack
in case of an exception. But this approximation is limited to suspension
points at await's in async functions. This depends on a recent ECMAScript
specification change, flagged behind --harmony-await-optimization and
implied the --async-stack-traces flag. Without this change there's no
way to get from the outer promise of an async function to the rest of
the promise chain, since the link is broken by the indirection introduced
by await.

For async functions the special outer promise, named .promise in the
Parser desugaring, is now forcible allocated to stack slot 0 during
scope resolution, to make it accessible to the stack frame construction
logic. Note that this first prototype doesn't yet work fully support
async generators and might have other limitations.

Bug: v8:7522
Ref: nodejs/node#11865
Change-Id: I0cc8e3cdfe45dab56d3d506be2d25907409b01a9
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1256762
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56363}
      f537d778
  25. 19 Sep, 2018 1 commit
  27. 18 Sep, 2018 1 commit
  29. 05 Sep, 2018 2 commits
    • Deepti Gandluri's avatar
      [wasm] Add runtime checks for misaligned atomic accesses · 2fcf6da4
      Deepti Gandluri authored 
      BUG: v8:6532, chromium:874809
Change-Id: I55c00e8563741908cf0daf263152ce927ae18e7c
Reviewed-on: https://chromium-review.googlesource.com/1205812
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: 's avatarBen Smith <binji@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55666}
      2fcf6da4
    • 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
  31. 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
  33. 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
  35. 08 Aug, 2018 1 commit
  37. 02 Aug, 2018 1 commit
    • Jungshik Shin's avatar
      Accept Etc/GMT* as a valid time zone id. · 4343e1a9
      Jungshik Shin authored 
      Etc/GMT* time zones are  listed in the INAN time zone database and
they should be accepted as valid.

This CL will be followed by a CL for moving time zone name checks to C++
that will accept all the time zone names (e.g. EST5EDT, Hongkong, ROK, Zulu).

Bug: chromium:364374
Test: intl/date-format/timezone.js
Test: mjsunit/regress/regress-crbug-364374
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: If0e5327d7e980504a9cb3d2b641e907ebce61180
Reviewed-on: https://chromium-review.googlesource.com/1159546
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54879}
      4343e1a9
  39. 25 Jul, 2018 1 commit
  41. 18 Jul, 2018 3 commits
  43. 10 Jul, 2018 1 commit
  45. 02 Jul, 2018 2 commits
  47. 18 May, 2018 1 commit
  49. 15 May, 2018 1 commit
  51. 23 Apr, 2018 1 commit
  53. 16 Apr, 2018 1 commit
  55. 22 Mar, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Reduce resolve element closure overhead in Promise.all. · d8658177
      Benedikt Meurer authored 
      In Promise.all we used to allocate a fresh closure plus a fresh context
for each individual element, which is quite a lot of overhead, especially
since this could be shared in a single context for all elements. The only
bit of information that is needed for each resolve element closure is the
index under which to store the resulting value. With this change we move
this index to the "identity hash" field of the JSFunction, which doesn't
care about the concrete value anyways, as long as it's not zero (the "no
hash" sentinel), and share the rest of the fields in a single outer
context for all resolve element closures.

This limits the maximum number of elements for Promise.all to 2^21 for
now, but that should be fine. Shall we ever see the need for more than
this, we can add machinery to overflow to separate context for indices
larger than 2^21.

This significantly reduces the overhead due to Promise.all on the
parallel-async-es2017-native test, with execution time dropping from
around 148ms to 133ms, so overall a steady 10% improvement on this
benchmark.

Bug: v8:7253
Change-Id: I1092da771c4919f3db7129d2b0a244fc26a7b144
Reviewed-on: https://chromium-review.googlesource.com/973283Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52134}
      d8658177
  57. 15 Mar, 2018 2 commits
  59. 14 Mar, 2018 1 commit
  61. 06 Mar, 2018 1 commit
  63. 01 Mar, 2018 2 commits
  65. 26 Feb, 2018 1 commit