Skip to content

V
V8
Switch branch/tag
  1. 04 Jul, 2018 1 commit
  3. 02 Jul, 2018 1 commit
  5. 18 Jun, 2018 2 commits
  7. 15 Jun, 2018 1 commit
  9. 13 Apr, 2018 1 commit
  11. 09 Apr, 2018 1 commit
  13. 06 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored 
      This reverts commit f9a2e24b.

Reason for revert: gc stress failures not all fixed by follow up.

Original change's description:
> [cleanup] Refactor the Factory
> 
> There is no good reason to have the meat of most objects' initialization
> logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
> this CL changes the protocol between Heap and Factory to be AllocateRaw,
> and all object initialization work after (possibly retried) successful
> raw allocation happens in the Factory.
> 
> This saves about 20KB of binary size on x64.
> 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
> Reviewed-on: https://chromium-review.googlesource.com/959533
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52416}

TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org

Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored 
      There is no good reason to have the meat of most objects' initialization
logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
this CL changes the protocol between Heap and Factory to be AllocateRaw,
and all object initialization work after (possibly retried) successful
raw allocation happens in the Factory.

This saves about 20KB of binary size on x64.

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
Reviewed-on: https://chromium-review.googlesource.com/959533
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b
  15. 05 Apr, 2018 1 commit
  17. 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
  19. 13 Mar, 2018 1 commit
  21. 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
  23. 09 Mar, 2018 1 commit
    • 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
  25. 05 Mar, 2018 1 commit
  27. 20 Feb, 2018 1 commit
  29. 12 Feb, 2018 1 commit
    • 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
  31. 03 Feb, 2018 1 commit
  33. 29 Jan, 2018 1 commit
  35. 24 Jan, 2018 1 commit
  37. 11 Jan, 2018 1 commit
    • Caitlin Potter's avatar
      Reland "[esnext] load `iterator.next` only once at beginning of iteration" · 2d889aa9
      Caitlin Potter authored 
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
september 2017 TC39 meetings. This moves the load of the "next" method
to the very beginning of the iteration protocol, rather than during
each iteration step.

This impacts:

- yield*
- for-of loops
- spread arguments
- array spreads

In the v8 implementation, this also affects async iteration versions of
these things (the sole exception being the Async-From-Sync iterator,
which requires a few more changes to work with this, likely done in a
followup patch).

This change introduces a new AST node, ResolvedProperty, which can be used
as a callee by Call nodes to produce the same bytecode as Property calls,
without observably re-loading the property. This is used in several
AST-desugarings involving the iteration protocol.

BUG=v8:6861, v8:5699
R=rmcilroy@chromium.org
TBR=neis@chromium.org, adamk@chromium.org

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b
Reviewed-on: https://chromium-review.googlesource.com/857593
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50518}
      2d889aa9
  39. 09 Jan, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[esnext] load `iterator.next` only once at beginning of iteration" · 163b5d70
      Michael Achenbach authored 
      This reverts commit bf4cc9ee.

Reason for revert: Breaks windows with msvc and linux with gcc
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265

Original change's description:
> [esnext] load `iterator.next` only once at beginning of iteration
> 
> https://github.com/tc39/ecma262/pull/988 gained concensus during the
> september 2017 TC39 meetings. This moves the load of the "next" method
> to the very beginning of the iteration protocol, rather than during
> each iteration step.
> 
> This impacts:
> 
> - yield*
> - for-of loops
> - spread arguments
> - array spreads
> 
> In the v8 implementation, this also affects async iteration versions of
> these things (the sole exception being the Async-From-Sync iterator,
> which requires a few more changes to work with this, likely done in a
> followup patch).
> 
> This change introduces a new AST node, ResolvedProperty, which can be used
> as a callee by Call nodes to produce the same bytecode as Property calls,
> without observably re-loading the property. This is used in several
> AST-desugarings involving the iteration protocol.
> 
> BUG=v8:6861, v8:5699
> R=​rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
> 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
> Reviewed-on: https://chromium-review.googlesource.com/687997
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50452}

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

Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6861, v8:5699
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/857616Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50454}
      163b5d70
    • Caitlin Potter's avatar
      [esnext] load `iterator.next` only once at beginning of iteration · bf4cc9ee
      Caitlin Potter authored 
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
september 2017 TC39 meetings. This moves the load of the "next" method
to the very beginning of the iteration protocol, rather than during
each iteration step.

This impacts:

- yield*
- for-of loops
- spread arguments
- array spreads

In the v8 implementation, this also affects async iteration versions of
these things (the sole exception being the Async-From-Sync iterator,
which requires a few more changes to work with this, likely done in a
followup patch).

This change introduces a new AST node, ResolvedProperty, which can be used
as a callee by Call nodes to produce the same bytecode as Property calls,
without observably re-loading the property. This is used in several
AST-desugarings involving the iteration protocol.

BUG=v8:6861, v8:5699
R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
Reviewed-on: https://chromium-review.googlesource.com/687997
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50452}
      bf4cc9ee
  41. 04 Jan, 2018 1 commit
  43. 19 Dec, 2017 2 commits
  45. 18 Dec, 2017 2 commits
  47. 15 Dec, 2017 3 commits
  49. 12 Dec, 2017 1 commit
  51. 27 Nov, 2017 1 commit
    • Sathya Gunasekaran's avatar
      [class] Store class fields initializer on the constructor · 4ca9d843
      Sathya Gunasekaran authored 
      Previously, the class fields initializer function was stored on a
synthetic context allocated variable. This approach had sevaral
problems:

- We didn't know that class literal had fields until after we had
completely parsed the class literal. This meant that we had to go back
and fix up the scope of the constructor to have this synthetic
variable. This resulted in mismatch between parser and preparsed scope
data.

- This synthetic variable could potentially resolve to an initializer
of an outer class.

For ex:
class X extends Object {
  c = 1;
  constructor() {
    var t = () => {
      class P extends Object {
        constructor() {
          var t = () => { super(); };
          t();
        }
      }
      super();
    }
    t();
  }
}

In this the inner class P could access the outer class X's initiliazer
function. We would have to maintain extra metadata to make sure this
doesn't happen.

Instead this new approach uses a private symbol to store the
initializer function on the class constructor itself.

For the base constructor case, we can simply check for a bit on the
constructor function literal to see if we need to emit code that loads
and calls this initializer function. Therefore, we don't pay the cost
of loading this function in case there are no class fields.

For the derived constructor case, there are two possiblities:
(a) We are in a super() call directly in the derived constructor:

In this case we can do a check similar to the base constructor check,
we can check for a bit on the derived constructor and emit code for
loading and calling the initializer function.

This is usually the common case and we don't pay any cost for not using
class fields.

(b) We are in a super() call inside an arrow function in the derived
constructor:

In this case, we /always/ emit code to load and call the initializer
function. If the function doesn't exist then we have undefined and we
don't call anything. Otherwise we call the function.

super() can't be called twice so even if we emit code to load and call
the initializer function multiple times, it doesn't matter because it
would have already been an error.

Bug: v8:5367
Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88
Reviewed-on: https://chromium-review.googlesource.com/781660
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49628}
      4ca9d843
  53. 17 Nov, 2017 1 commit
  55. 16 Nov, 2017 1 commit
  57. 14 Nov, 2017 1 commit
    • Adam Klein's avatar
      [parser] RewritableExpressions should keep track of their Scope directly · 082009fc
      Adam Klein authored 
      Previously, the Parser stored a Scope alongside a RewritableExpression
for each potential destructuring assignment. This Scope was later used
during rewriting to set the correct context for the rewriting. But this
approach failed if a new Scope was inserted into the Scope chain between
the time the assignment was parsed and when it was rewritten.

By storing the Scope directly in RewritableExpression,
ReparentExpressionScopes() is able to appropriately re-scope such
expressions prior to their rewriting.

Bug: chromium:779457
Change-Id: Ieb429a3da841f76d5798610af59da4fccb000652
Reviewed-on: https://chromium-review.googlesource.com/767666
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49368}
      082009fc
  59. 13 Nov, 2017 1 commit
    • Adam Klein's avatar
      [parser] Greatly simplify Array spread rewriting code · 18cac20c
      Adam Klein authored 
      Since each Array literal containing a spread is individually queued for
rewriting, there's no need for an AstVisitor here: a simple linear
pass through the queue is sufficient.

This patch deletes AstExpressionRewriter and all the machinery supporting
it in the AST. This code was built with the idea of using it as
a general expression rewriting mechanism in the parser, but those use
cases never materialized, and Array spread remains the only thing
that used this code.

Bug: v8:6092
Change-Id: I754c4883099e840881b005f20216f86e57721d5a
Reviewed-on: https://chromium-review.googlesource.com/765051Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49337}
      18cac20c
  61. 10 Nov, 2017 2 commits
  63. 09 Nov, 2017 1 commit
    • Ross McIlroy's avatar
      [Ast] Teach Ast Printer to print raw literal values. · ff4e4ab4
      Ross McIlroy authored 
      Converts the ast prettyprinter to printing literals from the raw values
rather than internalized on-heap strings. This enables ast printing before
internalizing, and means we can avoid use of the isolate in the interpreter's
off-thread phase.

Also removes --print-builtin-ast and relies on just --print-ast to print
everything.

Finally, converts FunctionLiteral's debug_name function to return a
char[] which is created from the raw name literal where it exists, rather
than relying on the value having been internalized.

BUG=v8:5203

Change-Id: Ib69f754e254736f415db38713e6209465817e6f1
Reviewed-on: https://chromium-review.googlesource.com/758681Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49276}
      ff4e4ab4