Skip to content

V
V8
Switch branch/tag
  1. 13 Apr, 2018 1 commit
  3. 06 Apr, 2018 1 commit
  5. 27 Mar, 2018 1 commit
  7. 26 Mar, 2018 1 commit
    • Adam Klein's avatar
      Revert "Reland "[parser] Remove pretenuring of closures assigned to properties"" · 5cf2ae5a
      Adam Klein authored 
      This reverts commit 3d7ad2e7.

Reason for revert: too many regressions to handle for now.

Original change's description:
> Reland "[parser] Remove pretenuring of closures assigned to properties"
>
> The memory gains were significant, so despite the bluebird-doxbee
> regression, we think it's better to have this patch than not.
> See the attached Chromium bug for more discussion.
>
> This is a reland of 20e346bd.
>
> Original change's description:
> > [parser] Remove pretenuring of closures assigned to properties
> >
> > This pretenuring was added in https://codereview.chromium.org/5220007,
> > back when it was necessary in order to allow use of the closure
> > as a "constant function" property. This should no longer be the case,
> > and the pretenuring causes some unfortunate downstream effects.
> >
> > This patch removes the parser's setting of this bit. If it doesn't
> > cause regressions on the perf bots, followup CLs will remove the
> > rest of the support for this feature.
> >
> > Bug: v8:7442
> > Change-Id: I27c43dd4293ce5de921be6c78571e712778d138a
> > Reviewed-on: https://chromium-review.googlesource.com/914610
> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> > Commit-Queue: Adam Klein <adamk@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#51254}
>
> Bug: v8:7442, chromium:814182
> Change-Id: I228c59dccef3844803f115749e72ae6c5f286eda
> Reviewed-on: https://chromium-review.googlesource.com/938241
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Commit-Queue: Adam Klein <adamk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51668}

Tbr: gsathya@chromium.org
Bug: v8:7442, v8:7524, chromium:814182, chromium:818627, chromium:818672, chromium:819994, chromium:821788
Change-Id: Ib760d63f879613f3b874889c5cb29ba2a77ba430
Reviewed-on: https://chromium-review.googlesource.com/980795
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52233}
      5cf2ae5a
  9. 16 Mar, 2018 2 commits
  11. 15 Mar, 2018 2 commits
    • Sathya Gunasekaran's avatar
      [numeric separator] Simplify error handling · e77eebfe
      Sathya Gunasekaran authored 
      Pointing to the exact spot of the incorrect numeric separator seems
clearer both in terms of the error itself, and the resulting code in
scanner because we don't have to keep track of the start position.

Previously, the error was:
  ➜ ./out.gn/x64.release/d8 --harmony-numeric-separator -e '0x1__1'
  unnamed:1: SyntaxError: Only one underscore is allowed as numeric separator
  0x1__1
  ^^^^
  SyntaxError: Only one underscore is allowed as numeric separator

Now, the error is:
  ➜ ./out.gn/x64.release/d8 --harmony-numeric-separator -e '0x1__1'
  unnamed:1: SyntaxError: Only one underscore is allowed as numeric separator
  0x1__1
      ^
  SyntaxError: Only one underscore is allowed as numeric separator


Bug: v8:7317
Change-Id: I7df1b39816e51a97234da6ed0fca1bf8c0223c3e
Reviewed-on: https://chromium-review.googlesource.com/962241
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51950}
      e77eebfe
    • Sathya Gunasekaran's avatar
      [numeric separator] Ban implicit octal support · 9c983910
      Sathya Gunasekaran authored 
      Bug: v8:7317
Change-Id: I20fb706c05852668a5a6ae8b69c150ae2e6b2f65
Reviewed-on: https://chromium-review.googlesource.com/960901Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51943}
      9c983910
  13. 14 Mar, 2018 1 commit
    • Caitlin Potter's avatar
      Reland "[esnext] re-implement template strings" · b8229612
      Caitlin Potter authored 
      - Add a new bytecode for the ToString operation, replacing the old
intrinsic call (currently does not collect type feedback).
- Add a new AST node to represent TemplateLiterals, and avoid
generating unnecessary ToString operations in some simple cases.
- Use a single feedback slot for each string addition, because the
type feedback should always be the same for each addition

This seems to produce a very slight improvement on JSTests benchmarks
and bench-ruben.js from v8:7415, and it's possible that type feedback
for the ToString bytecode could provide more opportunities to eliminate
the runtime call in TurboFan.

Doesn't touch tagged templates

[esnext] fix OOB read in ASTPrinter::VisistTemplateLiteral

Fixes an error where TemplateLiteral printing in --print-ast
would try to read an element beyond the length of a vector.

BUG=v8:7415, chromium:820596
R=adamk@chromium.org, gsathya@chromum.org, rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org

Change-Id: Ie56894f73a6445550a5f95f42160c4e29ab1da42
Reviewed-on: https://chromium-review.googlesource.com/958408Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#51933}
      b8229612
  15. 13 Mar, 2018 1 commit
  17. 10 Mar, 2018 1 commit
    • Michael Achenbach's avatar
      Revert "[esnext] re-implement template strings" · b8128279
      Michael Achenbach authored 
      This reverts commit 8ae19e08.

Reason for revert:
Speculative revert for layout test:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/22215

See:
https://github.com/v8/v8/wiki/Blink-layout-tests

Original change's description:
> [esnext] re-implement template strings
> 
> - Add a new bytecode for the ToString operation, replacing the old
> intrinsic call (currently does not collect type feedback).
> - Add a new AST node to represent TemplateLiterals, and avoid
> generating unnecessary ToString operations in some simple cases.
> - Use a single feedback slot for each string addition, because the
> type feedback should always be the same for each addition
> 
> This seems to produce a very slight improvement on JSTests benchmarks
> and bench-ruben.js from v8:7415, and it's possible that type feedback
> for the ToString bytecode could provide more opportunities to eliminate
> the runtime call in TurboFan.
> 
> Doesn't touch tagged templates
> 
> BUG=v8:7415
> R=​rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
> 
> Change-Id: If5a8c68558431f058db894d65776324abf54218e
> Reviewed-on: https://chromium-review.googlesource.com/945408
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Cr-Commit-Position: refs/heads/master@{#51853}

TBR=rmcilroy@chromium.org,caitp@igalia.com,ishell@chromium.org,bmeurer@chromium.org

Change-Id: Id0529b065493ffc20c8f2b1abacc4c1484c3c046
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7415
Reviewed-on: https://chromium-review.googlesource.com/958163Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51862}
      b8128279
  19. 09 Mar, 2018 2 commits
    • Caitlin Potter's avatar
      [esnext] re-implement template strings · 8ae19e08
      Caitlin Potter authored 
      - Add a new bytecode for the ToString operation, replacing the old
intrinsic call (currently does not collect type feedback).
- Add a new AST node to represent TemplateLiterals, and avoid
generating unnecessary ToString operations in some simple cases.
- Use a single feedback slot for each string addition, because the
type feedback should always be the same for each addition

This seems to produce a very slight improvement on JSTests benchmarks
and bench-ruben.js from v8:7415, and it's possible that type feedback
for the ToString bytecode could provide more opportunities to eliminate
the runtime call in TurboFan.

Doesn't touch tagged templates

BUG=v8:7415
R=rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org

Change-Id: If5a8c68558431f058db894d65776324abf54218e
Reviewed-on: https://chromium-review.googlesource.com/945408Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#51853}
      8ae19e08
    • Peter Marshall's avatar
      [memory] Save space in the FeedbackMetadata on 64 bit platforms. · 5a70a5ea
      Peter Marshall authored 
      Previously we used a FixedArray for the FeedbackMetadata, packing bits
of information into Smi fields. On 64-bit platforms, we waste at least
half of the available memory by using the Smi representation.

Given that this is just raw data (no pointers), we can just use a new
type that uses the existing packing scheme to store the data in int32
format instead.

This CL changes FeedbackMetadata to a new subclass of HeapObject. This
is to reduce the API surface exposed, in comparison to extending/using
a more general purpose data structure like ByteArray, which is also just
raw data.

FeedbackMetadata only exposes general purpose methods for accessing
slots, but hides the implementation detail of packing bits into int32
fields.

This CL also introduces a sentinal EmptyFeedbackMetadata, because there
are ~750 empty FeedbackMetadata objects when running an empty program in
V8. These are probably for builtins.

Bug: v8:7500
Change-Id: Ic85563153abbd71a22854cee8519260c32b1e9ab
Reviewed-on: https://chromium-review.googlesource.com/945730
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51842}
      5a70a5ea
  21. 08 Mar, 2018 1 commit
  23. 06 Mar, 2018 1 commit
  25. 02 Mar, 2018 4 commits
    • Georg Neis's avatar
      [ic] Introduce new IC for storing into array literals. · 2e2860f7
      Georg Neis authored 
      ... and use it in the implementation of array literal spreads,
replacing calls to %AppendElement.

Array spreads in destructuring will be taken care of in a separate CL.

Bug: v8:5940, v8:7446
Change-Id: Idec52398902a7fd3c1244852cf73246f142404f0
Reviewed-on: https://chromium-review.googlesource.com/915364
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51709}
      2e2860f7
    • Georg Neis's avatar
      Reland "[parsing] inline ArrayLiteral creation for spread calls" · 82345e9f
      Georg Neis authored 
      This reverts commit f48e7349.

Reason for revert: innocent!!

Original change's description:
> Revert "[parsing] inline ArrayLiteral creation for spread calls"
> 
> This reverts commit 93fc3841.
> 
> Reason for revert: may break node.js integration
> 
> Original change's description:
> > [parsing] inline ArrayLiteral creation for spread calls
> > 
> > Instead of using runtime calls to generate the Array Literal passed to
> > %reflect_call / %reflect_construct, we create an ArrayLiteral from the
> > list of arguments, and perform spreads using the interpreter mechanism for
> > spreading in ArrayLiterals (thus, the spreading becomes inline). This
> > array literal is still passed to %reflect_call / %reflect_construct as
> > before.
> > 
> > This cuts the runtime for bench-spread-call.js -> testSpread roughly in
> > half, and will likely improve further once
> > https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed.
> > 
> > BUG=v8:7446
> > R=​neis@chromium.org, adamk@chromium.org
> > 
> > Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad
> > Reviewed-on: https://chromium-review.googlesource.com/939587
> > Commit-Queue: Georg Neis <neis@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#51678}
> 
> TBR=adamk@chromium.org,neis@chromium.org,caitp@igalia.com,bmeurer@chromium.org
> 
> Change-Id: I4730077591bce0e5e7b2ce7d59678e8b7135cc08
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:7446
> Reviewed-on: https://chromium-review.googlesource.com/945769
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51682}

TBR=adamk@chromium.org,neis@chromium.org,sigurds@chromium.org,caitp@igalia.com,bmeurer@chromium.org

Change-Id: I977513bea06a4f3fba03fa4a89270298475422e2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7446
Reviewed-on: https://chromium-review.googlesource.com/945808Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51686}
      82345e9f
    • Sigurd Schneider's avatar
      Revert "[parsing] inline ArrayLiteral creation for spread calls" · f48e7349
      Sigurd Schneider authored 
      This reverts commit 93fc3841.

Reason for revert: may break node.js integration

Original change's description:
> [parsing] inline ArrayLiteral creation for spread calls
> 
> Instead of using runtime calls to generate the Array Literal passed to
> %reflect_call / %reflect_construct, we create an ArrayLiteral from the
> list of arguments, and perform spreads using the interpreter mechanism for
> spreading in ArrayLiterals (thus, the spreading becomes inline). This
> array literal is still passed to %reflect_call / %reflect_construct as
> before.
> 
> This cuts the runtime for bench-spread-call.js -> testSpread roughly in
> half, and will likely improve further once
> https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed.
> 
> BUG=v8:7446
> R=​neis@chromium.org, adamk@chromium.org
> 
> Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad
> Reviewed-on: https://chromium-review.googlesource.com/939587
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51678}

TBR=adamk@chromium.org,neis@chromium.org,caitp@igalia.com,bmeurer@chromium.org

Change-Id: I4730077591bce0e5e7b2ce7d59678e8b7135cc08
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7446
Reviewed-on: https://chromium-review.googlesource.com/945769Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51682}
      f48e7349
    • Caitlin Potter's avatar
      [parsing] inline ArrayLiteral creation for spread calls · 93fc3841
      Caitlin Potter authored 
      Instead of using runtime calls to generate the Array Literal passed to
%reflect_call / %reflect_construct, we create an ArrayLiteral from the
list of arguments, and perform spreads using the interpreter mechanism for
spreading in ArrayLiterals (thus, the spreading becomes inline). This
array literal is still passed to %reflect_call / %reflect_construct as
before.

This cuts the runtime for bench-spread-call.js -> testSpread roughly in
half, and will likely improve further once
https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed.

BUG=v8:7446
R=neis@chromium.org, adamk@chromium.org

Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad
Reviewed-on: https://chromium-review.googlesource.com/939587
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51678}
      93fc3841
  27. 01 Mar, 2018 4 commits
  29. 26 Feb, 2018 1 commit
  31. 21 Feb, 2018 5 commits
  33. 20 Feb, 2018 1 commit
  35. 19 Feb, 2018 1 commit
  37. 16 Feb, 2018 1 commit
  39. 15 Feb, 2018 3 commits
  41. 14 Feb, 2018 2 commits
  43. 13 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Refactor the promise resolution and rejection logic. · c0412961
      Benedikt Meurer authored 
      This introduces dedicated builtins

  - FulfillPromise,
  - RejectPromise, and
  - ResolvePromise,

which perform the corresponding operations from the language
specification, and removes the redundant entry points and the
excessive inlining of these operations into other builtins. We
also add the same logic on the C++ side, so that we don't need
to go into JavaScript land when resolving/rejecting from the
API.

The C++ side has a complete implementation, including full support
for the debugger and the current PromiseHook machinery. This is to
avoid constantly crossing the boundary for those cases, and to also
simplify the CSA side (and soon the TurboFan side), where we only
do the fast-path and bail out to the runtime for the general handling.

On top of this we introduce %_RejectPromise and %_ResolvePromise,
which are entry points used by the bytecode and parser desugarings
for async functions, and also used by the V8 Extras API. Thanks to
this we can uniformly optimize these in TurboFan, where we have
corresponding operators JSRejectPromise and JSResolvePromise, which
currently just call into the builtins, but middle-term can be further
optimized, i.e. to skip the "then" lookup for JSResolvePromise when
we know something about the resolution.

In TurboFan we can also already inline the default PromiseCapability
[[Reject]] and [[Resolve]] functions, although this is not as effective
as it can be right now, until we have inlining support for the Promise
constructor (being worked on by petermarshall@ right now) and/or SFI
based CALL_IC feedback.

Overall this change is meant as a refactoring without significant
performance impact anywhere; it seems to improve performance of
simple async functions a bit, but otherwise is neutral.

Bug: v8:7253
Change-Id: Id0b979f9b2843560e38cd8df4b02627dad4b6d8c
Reviewed-on: https://chromium-review.googlesource.com/911632Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51260}
      c0412961
  45. 12 Feb, 2018 2 commits
    • Adam Klein's avatar
      [parser] Remove pretenuring of closures assigned to properties · 20e346bd
      Adam Klein authored 
      This pretenuring was added in https://codereview.chromium.org/5220007,
back when it was necessary in order to allow use of the closure
as a "constant function" property. This should no longer be the case,
and the pretenuring causes some unfortunate downstream effects.

This patch removes the parser's setting of this bit. If it doesn't
cause regressions on the perf bots, followup CLs will remove the
rest of the support for this feature.

Bug: v8:7442
Change-Id: I27c43dd4293ce5de921be6c78571e712778d138a
Reviewed-on: https://chromium-review.googlesource.com/914610Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51254}
      20e346bd
    • Caitlin Potter's avatar
      [esnext] implement spec change to TaggedTemplate callsite caching · d3ca0d00
      Caitlin Potter authored 
      Implements the change outlined in https://github.com/tc39/ecma262/pull/890,
which has been ratified and pulled into the specification. In particular,
template callsite objects are no longer kept in a global, eternal Map, but
are instead associated with their callsite, which can be collected. This
prevents a memory leak incurred by TaggedTemplate calls.

Changes, summarized:

    - Remove the TemplateMap and TemplateMapShape objects, instead caching
      template objects in the feedback vector.
    - Remove the `hash` member of TemplateObjectDescriptor, and the Equals
      method (used by TemplateMap)
    - Add a new FeedbackSlotKind (kTemplateObject), which behaves similarly
      to FeedbackSlotKind::kLiteral, but prevents eval caching. This ensures
      that a new feedback vector is always created for eval() containing tagged
      templates, even when the CompilationCache is used.
    - GetTemplateObject bytecode now takes a feedback index, and only calls
      into the runtime if the feedback is Smi::kZero (uninitialized).

BUG=v8:3230, v8:2891
R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org,
rmcilroy@chromium.org

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I7827bc148d3d93e2b056ebf63dd624da196ad423
Reviewed-on: https://chromium-review.googlesource.com/624564
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51248}
      d3ca0d00