Commit Graph

977 Commits

Author SHA1 Message Date
Igor Sheludko
46d1986812 [cleanup] Fix kPointerSize in tests
Bug: v8:8477, v8:8834
Change-Id: I9213cca077a2758b87a6cb95bcb01d0186c32098
Reviewed-on: https://chromium-review.googlesource.com/c/1472633
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59602}
2019-02-14 15:29:52 +00:00
Dan Elphick
5cc245ae75 [compile] Add support for lazy generation of source position tables
If enable_omit_source_positions is true (defaults to false), source
position tables are not generated when compiling bytecode. They will
then be regenerated when exceptions are thrown.

This adds a new function Compiler::CollectSourcePositions which given a
SharedFunctionInfo with bytecode but no source position table re-parses
and regenerates the bytecode but this time with source positions
collection enabled. Note this will reparse all inner functions that
have previously been compiled since the preparse data is no longer
available.

With the flag enabled there still 18 test failures mostly related to
debugging.

v8: 8510
Change-Id: I46dff9818d8a89c901ba8ae8df94dcaca83aa658
Reviewed-on: https://chromium-review.googlesource.com/c/1385165
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59595}
2019-02-14 11:26:35 +00:00
Z Duong Nguyen-Huu
2936e33cdb Bytecode expectation rebaseline autodiscovery should work on Window
Change-Id: Ie946870fc46aeeca36924f20dc82d4ea2a0c756f
Reviewed-on: https://chromium-review.googlesource.com/c/1446143
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59375}
2019-02-05 16:33:33 +00:00
Suraj Sharma
2f66cb221c [inspector] Improve uninitialized binding error message
The program:

    foo;
    let foo = 5;

…now produces:

    ReferenceError: Cannot access 'foo' before initialization

…instead of:

    ReferenceError: foo is not defined

Bug: v8:6513, v8:6951
Change-Id: I6c372626734570d5abeb1d0196b814dde02b9e3e
Reviewed-on: https://chromium-review.googlesource.com/c/1441151
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Suraj Sharma <surshar@microsoft.com>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59307}
2019-02-02 00:38:06 +00:00
Camillo Bruni
8b1b7deed6 [scope] Add Scope::ForEach helper to avoid recursion
Drive-by-fix:
- Inline Scope::num_parameters
- Provide inlineable DataGatheringScope destructor precheck

Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53
Reviewed-on: https://chromium-review.googlesource.com/c/1445879
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 16:22:59 +00:00
Z Duong Nguyen-Huu
0cabc54666 Throw TypeError if a proxy's [[OwnPropertyKeys]] returns dupes
Adding implementation for step 9 which is missing for spec:
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys
Update bytecode_expectations as well.

Bug v8:6776

Change-Id: Id191f9604e2dc08e71cbcff8ebd5707c233af193
Reviewed-on: https://chromium-review.googlesource.com/c/1419779
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59180}
2019-01-29 17:55:06 +00:00
Jakob Kummerow
c640296e5a [ubsan] Avoid signed left shifts
The workaround is simple: cast to unsigned before shifting.

Bug: v8:3770
Change-Id: I5f0f7af697ec5db0ab1df3d061008940c83c5c56
Reviewed-on: https://chromium-review.googlesource.com/c/1436215
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59140}
2019-01-28 20:43:47 +00:00
Leszek Swirski
ed15724846 [parser] Don't create proxies for vars without initialisers
Vars without initialisers don't need to allocate a VariableProxy, as the
proxy expression is not really needed for anything. So, we can special
case declaration parsing to look ahead for a '=' (plus a few other
cases), and skip the variable proxy allocation if it isn't there.

As a side-effect, variables that are only declared but never used are
no longer marked is_used, and thus not allocated. This saves on
generating dead code.

Change-Id: Ie4f04c6b5c1138df4c2e17acf1f0150459b3b571
Reviewed-on: https://chromium-review.googlesource.com/c/1434376
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59129}
2019-01-28 15:54:40 +00:00
Mythri
c082b74c96 Cleanup after removing language mode parameter from SetProperty
SetProperty now infers the language mode from the closure and the context
So we no longer have to pass around the language mode. Cleanup by
removing the parameter where it is no longer needed.

Bug: v8:8580
Change-Id: I89452b5a762eb48a911f158d22c7bfa9e3bb1be4
Reviewed-on: https://chromium-review.googlesource.com/c/1421840
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59089}
2019-01-25 10:51:10 +00:00
Leszek Swirski
08f68102f8 [parser] Allow declaring variables without a proxy
Declare Variables with a name and position, rather than by passing
through a VariableProxy. This allows us to not create dummy proxies
for things like function declarations, and allows us to consider those
declarations unused.

As a side-effect, we also have to check if a variable is unused in the
bytecode generator (as it will no longer be allocated), and we end up
skip generating code/SFIs for dead variables/functions.

Change-Id: I4c2c872473f23e124f9456b4b92f87159658f8e0
Reviewed-on: https://chromium-review.googlesource.com/c/1414916
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59088}
2019-01-25 09:10:59 +00:00
Toon Verwaest
0b69b05a08 [parser] Iterate declarations to set initializer positions
This allows us to remove the PatternRewriter.

Change-Id: I54ec74ed3bd31e76e38c69f9b0b2a78f8620cd89
Reviewed-on: https://chromium-review.googlesource.com/c/1429863
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59028}
2019-01-23 13:28:58 +00:00
Jakob Gruber
b766299d2c [arm] Add missing RELATIVE_CODE_TARGET iteration
Code object iteration was missing logic for RELATIVE_CODE_TARGET
reloc entries. Garbage collection could thus miss objects that were
referenced only as targets of pc-relative calls or jumps.

RELATIVE_CODE_TARGETs are only used on arm, mips, and s390 and only
at mksnapshot-time.

This exposed another issue in that the interpreter entry trampoline
copy we generate for profiling *did* contain relative calls in
runtime-accessible code. This is a problem, since code space on arm is,
by default, too large to be fully addressable through pc-relative
calls. This CL thus also disables the related
FLAG_interpreted_frames_native_stack feature on arm.

Drive-by: Ensure the builtins constants table does not contain Code
objects.

Bug: v8:8713,v8:6666
Change-Id: Idd914b46970ad08f9091fc72113fa7aed2732e71
Reviewed-on: https://chromium-review.googlesource.com/c/1424866
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59023}
2019-01-23 10:45:50 +00:00
Matt Gardner
1e5b2358a7 Check for "SuperNotCalled" on "delete this" in a constructor
V8 implements "delete this" as "LdaTrue", but an error needs to be thrown
if done in a constructor before calling super. ThrowIfHole checks the
accumulator, so we need to load 'this' into the accumulator. The check is
inserted by the load since it has HoleCheckMode::kRequired

Bug: https://bugs.chromium.org/p/v8/issues/detail?id=6711

Change-Id: I9f2ce4439505cec4327d88d1195898782edea721
Reviewed-on: https://chromium-review.googlesource.com/c/1419084
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Matt Gardner <magardn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59007}
2019-01-22 18:58:42 +00:00
Ross McIlroy
162402f9c5 [Compile] Move decision of whether an IIFE is oneshot into parser.
The decision as to whether to optimize an IIFE as oneshot depends on
whether it's outer scope is the script scope. During lazy compile, we
might have discarded scopes which don't need a context between the IIFE
and the script scope, which means we might treat an IIFE as oneshot,
even though initial eager compile treated it as non-oneshot. Both
bytecode flushing and lazy source positions rely on us generating the
same bytecode during lazy compile as eager compile, so we move the
decision into the parser where it happens once and is then stored in
the SFI for any future lazy compiles.

BUG=v8:8395,v8:8510

Change-Id: I88f1e74ad95d47a2636c393ceb1318d7d610055d
Reviewed-on: https://chromium-review.googlesource.com/c/1421841
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58996}
2019-01-22 15:19:39 +00:00
Peter Marshall
decfb42aeb [logger] Untangle log.h includes
Everything was including log.h through heap-inl.h, so remove that
include by moving the one user into heap.cc, and then fix all the
include errors.

This reduces the log.h include ball from ~550 to ~100.

Change-Id: I6d09bc2f365b48645fcfdc695a68ea12539a745d
Reviewed-on: https://chromium-review.googlesource.com/c/1424198
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58981}
2019-01-22 10:56:52 +00:00
Toon Verwaest
c45850cd1e [parser] Declare variables through ExpressionScope
Use variable tracking from ExpressionScopes rather than the PatternRewriter and
PreParserExpression::variables_ to declare variables.

We only figure out that variables are non-simple parameters once we see the
first non-simple parameter. This still uses the pattern rewriter to make
variables non-simple (kLet instead of kVar).

Change-Id: I4a4ee4852d667c26806bb24896722cfea3e093f2
Reviewed-on: https://chromium-review.googlesource.com/c/1417630
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58954}
2019-01-21 11:37:32 +00:00
Toon Verwaest
8436715fe6 [parser] Give hoisting sloppy block functions a valid position
A sloppy function in a block scope implicitily creates a var in the outer
declaration scope if it's not blocked. The assignment created reads the local
lexical declaration for the function. The reference introduced automatically
takes part in NeedsHoleCheck, requiring the reference to have a valid position.
Since the assignment will happen after the local declaration, we give the
end_position() of the closure as the position of the reference, so hole checks
can be omitted.

Bug: chromium:917755
Change-Id: Iee0e042b2463f97f05075f9eec09dac8c6eaf539
Reviewed-on: https://chromium-review.googlesource.com/c/1408991
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58823}
2019-01-15 11:52:28 +00:00
Leszek Swirski
b4a3af9157 [ignition] Move for-of desugaring to bytecode
This removes the iteration protocol from the parser entirely, and opens
up future possibilities for more bytecodes implementing the various
functions of the protocol.

Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb
Reviewed-on: https://chromium-review.googlesource.com/c/1403125
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58795}
2019-01-14 16:37:41 +00:00
Leszek Swirski
5e2c23e2d3 [destructuring] Get non-coercible message contents in runtime
For desrtucturing assignments from null/undefined, we throw an error
that references the destructuring object literal's property name, e.g.
for
  var { x } = null;
we report that we cannot destructure 'x' from null.

Rather than calculating this property during bytecode generation (and
including it in the bytecode as an argument to the type error
constructor), we can calculate it at exception throwing time, by
re-parsing the source in a similar way to the existing call site
rendering.

This slightly decreases bytecode size and slightly decreases the amount
of work the bytecode compiler needs to do. In the future, it could also
allow us to give more detailed error messages, as we now have access to
the entire AST and are on the slow path anyway.

Bug: v8:6499
Change-Id: Icdbd4667db548b4e5e62ef97797a3771b5c1bf72
Reviewed-on: https://chromium-review.googlesource.com/c/1396080
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58706}
2019-01-10 15:23:05 +00:00
Leszek Swirski
f9a858fc96 [ignition] Remove useless iterator 'done' setting
The 'done' setting dance in BuildFillArrayWithIterator turned out to
not be useful, as the StoreInArrayLiteral call could not ever throw an
exception. Since iterator exceptions count as done, we are guarnteed to
be done as soon as we enter the loop.

Change-Id: Ibe2ba1fcbe383bfcfedb185169890b6931cc7884
Reviewed-on: https://chromium-review.googlesource.com/c/1402792
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58695}
2019-01-10 11:37:42 +00:00
Leszek Swirski
7fbbce5fa1 [ignition] Fix iteration finalization exception suppression
The IteratorClose spec specifies that exceptions in
%GetMethod(iterator.return) are not suppressed by exceptions in the
given continuation (body of a loop, assignments in destructuring),
while exceptions in the execution of iterator.return() are.

This means that we have to split out the property access + a typeof
check to be outside the try-catch, and keep the call inside of it.

The non-split version is only for cases when there is no 'throws'
continuation (as is the case for yield* calling IteratorClose), so
the existing BuildIteratorClose can be renamed to reflect this.

Change-Id: Id71aea4fddd6ffb986bd9aaa09d29615a8800f71
Reviewed-on: https://chromium-review.googlesource.com/c/1402789
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58694}
2019-01-10 11:29:12 +00:00
Leszek Swirski
5e725a2b43 [parser] Don't desugar destructuring declarations.
Emit a single destructuring assignment for destructuring declarations,
which can be desugared by the bytecode generator. This allows us to
remove destructuring desugaring from the parser (specifically, the
pattern rewriter) entirely.

The pattern "rewriter" is now only responsible for walking the
destructuring pattern to declare variables, mark them assigned, and
potentially rewrite scopes for the edge case of parameters with a sloppy
eval.

Note that since the rewriter is no longer rewriting, we have to flip the
VariableProxy copying logic for var re-lookup, so that we now pass the
new VariableProxy to the variable declaration and leave the original
unresolved (rather than passing the original through and rewriting to a
new unresolved VariableProxy).

This change does have some effect on breakpoint locations, due to some
of the available information changing between the parser and bytecode
generator, however the new locations appear to be more consistent
between assignments and declarations.

Change-Id: I3a58dd0a387d2bfb8e5e9e22dde0acc5f440cb82
Reviewed-on: https://chromium-review.googlesource.com/c/1382462
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58670}
2019-01-09 14:09:23 +00:00
Dan Elphick
3427ec9dfb [intepreter] Make bytecode mismatch failures more verbose
Print all the mismatch failures in the bytecode rather than aborting at
the first mismatch.

R=rmcilroy

Change-Id: Id572ead5fdc4d126ac9a05942f940b0eaef7150f
Reviewed-on: https://chromium-review.googlesource.com/c/1400412
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58628}
2019-01-08 12:58:15 +00:00
Joyee Cheung
5d40e9de86 [class] show private name in invalid private field access
This patch sets the name slot of the private name symbols for
private fields and display the names in error messages of invalid
private field accesses.

TBR: adamk@chromium.org
Bug: v8:8144
Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76
Reviewed-on: https://chromium-review.googlesource.com/c/1374332
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#58601}
2019-01-07 19:26:23 +00:00
Leszek Swirski
00a2481a24 [ignition] Move destructuring assignments to bytecode generation
Instead of de-sugaring destructuring assignment in the parser (using the
pattern rewriter), pass the Object/ArrayLiterals through to the bytecode
generator, which can desugar them in-place.

This allows us to decrease the amount of AST node creation, and improve
the generated bytecode using domain-specific knowledge. As a side effect
we partially fix an old execution ordering spec bug.

Currently only implemented for assignments, not declarations, as the
latter has some additional complexity.

Bug: v8:4951
Change-Id: I3d69d232bea2968ef20df68a74014d9e05808cfe
Reviewed-on: https://chromium-review.googlesource.com/c/1375660
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58512}
2019-01-03 09:41:27 +00:00
Bruce Dawson
4bd1215c95 Workaround VS/UCRT fmod bug
Recent versions of the Windows Universal CRT changed the behavior of
fmod for when the first parameter is negative. In particular, a result
of negative zero became positive zero. This is rarely critical but it
causes test failures and may effect some JS test suites or web pages.

The fix is to modify Modulo to check for a result of 0 when the first
parameter is negative and change the result to -0. That fixes four of
the five test failures and the fifth one is fixed by comparing the
results against Modulo instead of std::fmod.

Bug: chromium:915045
Change-Id: Ia4490ec98361a37006d6c338acd33f959fa3ccea
Reviewed-on: https://chromium-review.googlesource.com/c/1383091
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58377}
2018-12-19 18:05:18 +00:00
Mythri
1ca0de67d2 [reland] Don't allocate feedback vectors and feedback metadata in lite mode
Don't allocate feedback vectors and feedback metadata in lite mode.
Also updates to skip tests that require feedback vectors.

This is a reland of
https://chromium-review.googlesource.com/c/v8/v8/+/1384087 after skipping
the failing tests.

Bug: v8:8394
Change-Id: I7766533b85a144e62996ceed8d542cdc534feeb5
Reviewed-on: https://chromium-review.googlesource.com/c/1384307
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58363}
2018-12-19 14:29:30 +00:00
Clemens Hammacher
9efa28bf00 Revert "Do not allocate feedback vectors and feedback metadata in lite mode"
This reverts commit 62e86b88e5.

Reason for revert: Fails on arm sim lite debug: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite%20-%20debug/1075

Original change's description:
> Do not allocate feedback vectors and feedback metadata in lite mode
> 
> Don't allocate feedback vectors and feedback metadata in lite mode.
> Also updates to skip tests that require feedback vectors.
> 
> Bug: v8:8394
> Change-Id: I22c64a32c44bb8f25fb09003d6e9fc5a04e84f8a
> Reviewed-on: https://chromium-review.googlesource.com/c/1378173
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58351}

TBR=rmcilroy@chromium.org,yangguo@chromium.org,mlippautz@chromium.org,mythria@chromium.org

Change-Id: I88fd37ea4e21aa2cc81eceb87ddb35c23224beae
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8394
Reviewed-on: https://chromium-review.googlesource.com/c/1384087
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58355}
2018-12-19 11:31:32 +00:00
Mythri
62e86b88e5 Do not allocate feedback vectors and feedback metadata in lite mode
Don't allocate feedback vectors and feedback metadata in lite mode.
Also updates to skip tests that require feedback vectors.

Bug: v8:8394
Change-Id: I22c64a32c44bb8f25fb09003d6e9fc5a04e84f8a
Reviewed-on: https://chromium-review.googlesource.com/c/1378173
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58351}
2018-12-19 10:30:48 +00:00
Jakob Kummerow
766ef168fb [objects.h splitting] Move HeapNumber to heap-number.h
Along with HeapNumberBase and MutableHeapNumber, of course.

Bug: v8:5402
Change-Id: I14a7f8052de3839cad36bb7e4ebb6da38b2ac096
Reviewed-on: https://chromium-review.googlesource.com/c/1379884
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58293}
2018-12-17 17:58:09 +00:00
Jakob Kummerow
ec04cd33fc [ubsan] Port Struct subclasses, part 6
FeedbackCell, FunctionTemplateRareData, TemplateInfo,
FunctionTemplateInfo, ObjectTemplateInfo

Bug: v8:3770
Change-Id: Ic30ff2563fe30088b7740d5e98ade03cdae7fdd8
Reviewed-on: https://chromium-review.googlesource.com/c/1377459
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58274}
2018-12-17 11:34:43 +00:00
Leszek Swirski
a176aec77f [ignition] Add golden files for destructuring assignment
Change-Id: I71c6e52229cae2aba0a5aec1844c0643484354e5
Reviewed-on: https://chromium-review.googlesource.com/c/1375657
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58218}
2018-12-13 12:39:02 +00:00
Mythri
a36f2593ed Don't use feedback vector to infer IC kind and language mode
Currently, the runtime IC functions deduce the IC kind and the language
mode from the feedback slot kind. To support feedback free execution
(for V8 lite mode and lazy allocation of feedback vectors) we need to
infer the IC kind even when feedback vectors are not present.

To be able to infer the language mode without feedback vectors, this cl
forces context allocation in cases where we raise the language mode in
the middle of a function. The language mode is the stricter of the
language mode on the SFI and the language mode of the current context.

This cl updates the bytecode handlers to check for valid feedback vectors
and to call into runtime if the feedback vector is not allocated. It also
adds new runtime functions to be able to infer the IC kind when there is no
feedback vector. Most of the builtins and handlers remain unchanged because
they are only used when feedback vector is present.

Bug: v8:8394
Change-Id: I1f77740c0d68ddaa0de076597f5f6bcb2e966d70
Reviewed-on: https://chromium-review.googlesource.com/c/1358516
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58191}
2018-12-12 14:50:21 +00:00
Ross McIlroy
7d3826ea48 [Compile] Update JSFunction predicates to handle bytecode flushing.
Update is_compiled() and has_feedback_vector() to return false in the case
where the SFI's bytecode has been flushed, but the JSFunction hasn't yet been
reset to uncompiled. Also add code to reset the JSFunction when it is recompiled
lazily.

BUG=v8:8394

Change-Id: I7c5f79066603ac1ae097a0a62c625b1a8e39431c
Reviewed-on: https://chromium-review.googlesource.com/c/1363138
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58148}
2018-12-11 10:54:29 +00:00
Leszek Swirski
5e8301fd25 Revert "[parser] Improve error message for unclosed function bodies"
This reverts commit 92db073fce.

Reason for revert: Breaks devtools test https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Win/15539

Devtools seems to parse our error messages, e.g. https://cs.chromium.org/chromium/src/third_party/blink/renderer/devtools/front_end/object_ui/JavaScriptAutocomplete.js?type=cs&q=isExpressionComplete+javascriptautocomplete&sq=package:chromium&g=0&l=612

Original change's description:
> [parser] Improve error message for unclosed function bodies
> 
> This patch changes the output from:
> 
>   function fn() {
>                 ^
>   SyntaxError: Unexpected end of input
> 
> to:
> 
>   function fn() {
>                 ^
>   SyntaxError: missing '}' after function body
> 
> Bug: v8:6513, v8:7321
> Change-Id: I4ca8a40fa0be246da2a3ff776b3fb3c87b4ba4e0
> Also-By: gsathya@chromium.org
> Reviewed-on: https://chromium-review.googlesource.com/c/1367448
> Commit-Queue: Mathias Bynens <mathias@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58116}

TBR=marja@chromium.org,gsathya@chromium.org,mathias@chromium.org

Change-Id: Ia2ac413d67fda39eda903c056002ae632df73df9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6513, v8:7321
Reviewed-on: https://chromium-review.googlesource.com/c/1370026
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58124}
2018-12-10 13:09:07 +00:00
Mathias Bynens
92db073fce [parser] Improve error message for unclosed function bodies
This patch changes the output from:

  function fn() {
                ^
  SyntaxError: Unexpected end of input

to:

  function fn() {
                ^
  SyntaxError: missing '}' after function body

Bug: v8:6513, v8:7321
Change-Id: I4ca8a40fa0be246da2a3ff776b3fb3c87b4ba4e0
Also-By: gsathya@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/1367448
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58116}
2018-12-10 08:15:57 +00:00
Mathias Bynens
2096094cea Remove bytecode expectations for do expressions
Now that `do` expressions have been removed [1], we should remove the
corresponding golden file as well.

[1]: 58988c6c63

Change-Id: I4a6908d4d53b2bce1d9f2d616c672b4caf15adac
Reviewed-on: https://chromium-review.googlesource.com/c/1365283
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58084}
2018-12-07 08:26:45 +00:00
Jakob Kummerow
f53d4d70a9 [ubsan] Port FeedbackVector and FeedbackMetadata
to the new design.

Bug: v8:3770
Change-Id: I63291cc8eccfa1da20e84c6d3e9f48f253409396
Reviewed-on: https://chromium-review.googlesource.com/c/1355627
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57981}
2018-11-30 20:00:20 +00:00
Jakob Kummerow
0f581e4b99 [ubsan] Port Name/String/Symbol to the new design
Bug: v8:3770
Change-Id: I4da6404aa968adca1fbb49029fc304622101d6c3
Reviewed-on: https://chromium-review.googlesource.com/c/1349112
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57853}
2018-11-27 01:42:36 +00:00
Jakob Kummerow
8bb236d7c9 [ubsan] Port FixedArray{,Base} to the new design
Removing the temporarily duplicated classes FixedArrayPtr and
FixedArrayBasePtr.

Bug: v8:3770
Change-Id: I056ad74ff69593e9f134ef5c976766812c4d9275
Reviewed-on: https://chromium-review.googlesource.com/c/1345913
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57807}
2018-11-25 03:08:14 +00:00
Joyee Cheung
603bab1e49 [class] parse private methods
This patch implements the parsing of private methods
in the stage 3 proposal https://tc39.github.io/proposal-private-methods

- Adds a --harmony-private-methods flag
- Parse the private methods/accessors

The design doc is in
https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit?usp=sharing

This patch only makes sure the syntax parses, doesn't implement
the semantics.

Bug: v8:8330
Change-Id: I9007b3b3dd6a0df35db7bb14f38f1a38d52bc663
Reviewed-on: https://chromium-review.googlesource.com/c/1329706
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57615}
2018-11-19 17:42:38 +00:00
Jakob Gruber
6e5671e1cd [nojit] Embed InterpreterEntryTrampoline
This marks the InterpreterEntryTrampoline as isolate-independent. With
this change, all builtins are now embedded.

Slight changes were needed to how we deopt into the trampoline. We now
store the entry address within the Interpreter class instead of
embedding the builtin code target.

Bug: v8:7777
Change-Id: If781bf6f06cb2efbab1369ece757f04c343a1b38
Reviewed-on: https://chromium-review.googlesource.com/c/1337734
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57563}
2018-11-16 09:36:05 +00:00
Leszek Swirski
7aac6bc905 [cleanup] Make unicode predicate cache tables static
Moves the unicode predicate cache tables out of the unicode cache,
and turns them into generic predicates in char-predicates.h which
use static constexpr tables.

This drops the per-isolate cost of unicode caches, and removes the
need for accessing the unicode cache from most files. It does remove
the mutability of the cache, which means that there may be regressions
when parsing non-ASCII identifiers. Most likely the benefits to ASCII
identifiers/keywords will outweigh any non-ASCII costs.

Change-Id: I9a7a8b7c9b22d3e9ede824ab4e27f133ce20a399
Reviewed-on: https://chromium-review.googlesource.com/c/1335564
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57506}
2018-11-14 15:33:45 +00:00
Jakob Kummerow
fe61cd6487 [ubsan] Port Code to the new design
Bug: v8:3770
Change-Id: I413ce57f7fa91cef2445995ca22650477f92b0df
Reviewed-on: https://chromium-review.googlesource.com/c/1321892
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57445}
2018-11-12 18:47:04 +00:00
Toon Verwaest
58988c6c63 [parser] Remove broken/half-implemented do-expressions
The current implementation isn't very helpful anyway if we ever really want
this.

Change-Id: Iad4132734980937aee462a1613d47887383585a0
Reviewed-on: https://chromium-review.googlesource.com/c/1328928
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57388}
2018-11-09 13:22:56 +00:00
Jaroslav Sevcik
60c0edc08c [interpreter] Store CreateObjectLiteral's result into the accumulator.
As opposed to the register.

For subtle reasons, this fixes a deoptimizer bug with handling return
values in lazy deopt. Since the return values can now only overwrite
the accumulator, there is no danger of overwriting a captured object
that might be later used (since there is no "later").

Bug: chromium:902608
Change-Id: I3a7a10bb1c7a6f4303a01d60f80680afcb7bc942
Reviewed-on: https://chromium-review.googlesource.com/c/1325901
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57349}
2018-11-08 10:31:45 +00:00
Joyee Cheung
6c3d784c16 Rename fields to names or members
Rename variables and flag names so that the classes can be reused
by private methods implementation.

In particular:

Rename "fields" to "members" in the initializer so that we can
initialize both fields and private methods/accessors there,
for example:

instance_fields_initializer -> instance_members_initializer
InitializeClassFieldsStatement -> InitializeClassMembersStatement

Rename "private field" to "private name" for the private symbols
used to implement private fields so that we can use them to
store private methods/accessors later as well, for example:

private_field_name_var -> private_name_var
NewPrivateFieldSymbol -> NewPrivateNameSymbol

The follow-on is in
https://chromium-review.googlesource.com/c/v8/v8/+/1301018

The design doc is in
https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit?usp=sharing

Bug: v8:8330
Change-Id: I1cdca8def711da879b6e4d67c5ff0a5a4a36abbe
Reviewed-on: https://chromium-review.googlesource.com/c/1312597
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#57289}
2018-11-06 16:04:08 +00:00
Jakob Kummerow
6d706ae3a0 [ubsan] Port Smi to the new design
and split Smi out of objects.h into smi.h.

Bug: v8:3770, v8:5402
Change-Id: I5ff7461495d29c785a76c79aca2616816a29ab1e
Reviewed-on: https://chromium-review.googlesource.com/c/1313035
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57252}
2018-11-05 20:52:51 +00:00
Jakob Gruber
f5ef9f363a [builtins] Remove lazy deserialization
Now that embedded builtins are enabled everywhere*, lazy
deserialization can be turned off and removed.

* Except nosnap builds, on aix and in msvc builds.

Bug: v8:6666, v8:6624, v8:7990
Change-Id: Ib5fefe10e7ff35b13a1eb803fbc3736b8851b22b
Reviewed-on: https://chromium-review.googlesource.com/c/1288638
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57064}
2018-10-29 10:16:33 +00:00
Jakob Kummerow
e7b8699910 [ubsan] Port MaybeObject to new design
This CL applies the equivalent of the Object -> ObjectPtr
transformation to MaybeObject and HeapObjectReference. We
need no renaming in this case because we can just migrate
them both in one go.

Bug: v8:3770
Change-Id: Ie1259c3e8c556eff00f8bcf534d7270ca9fe00e1
Reviewed-on: https://chromium-review.googlesource.com/c/1298386
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57010}
2018-10-26 01:08:30 +00:00
Creddy
46aecaa6ef Add bytecode-generator test for function in assignments
Adding test to confirm that no one-shot optimizations are not done
for functions enclosed in parentheses but not immediately invoked
in an assignment.

Bug: v8:8072
Change-Id: I282132a7cc570b59290f2ec314462be060d48e5a
Reviewed-on: https://chromium-review.googlesource.com/c/1238576
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56763}
2018-10-18 09:22:36 +00:00
Benedikt Meurer
9f28c129a0 [async] Introduce the notion of a "current microtask".
Change the way we start collecting async stack traces by storing the
current microtask as a root instead of trying to make sense of the
last frame we see. This makes it possible to use the zero cost async
stack traces in Node.js as well (where the last JavaScript frame we
see is not the actual async function, but some frame related to the
main event loop usually).

In addition to the benefit that it now works with Node.js, we can also
extend the new machinery to look through (almost arbitrary) promise
chains. For example this code snippet

```js
(async function() {
  await Promise.resolve().then(() =>
    console.log(new Error().stack));
})();
```

can be made to also show the async function frame, even though at the
point where the stack trace is collected we don't have any async
function on the stack. But instead there's a PromiseReactionJobTask
as "current microtask", and we can dig into the chained promise to
see where the async execution is going to continue and eventually
find the await promise in the chain.

This also removes the removes the need to allocate `.generator_object`
specially during scope resolution.

Bug: v8:7522
Ref: nodejs/node#11865
Tbr: ulan@chromium.org
Design-Document: bit.ly/v8-zero-cost-async-stack-traces
Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203
Reviewed-on: https://chromium-review.googlesource.com/c/1277505
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56590}
2018-10-12 08:42:53 +00:00
Benedikt Meurer
a63987a41a [async] Introduce dedicated JSAsyncFunctionObject.
This JSAsyncFunctionObject represents the implicit generator object
inside of async functions, and also holds the outer promise for the
async functions. This in turn allows us to get rid of the .promise
in the Parser / BytecodeGenerator completely, and will make it
possible to build zero-cost async stack traces independent of the
concrete synchronous part of the stack frame (which currently breaks
in Node.js).

In the bytecode all the async function operations now take this new
JSAsyncFunctionObject instead of passing both the .generator_object
and the .promise, which further simplifies and shrinks the bytecode.
It also reduces the size of async function frames, potentially making
the suspend/resume cheaper.

This also changes `await` to use intrinsics instead of calling to
special JSFunctions on the native context, and thus reduces the size of
the native contexts.

Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator
to TurboFan.

Bug: v8:7253, v8:7522
Change-Id: I2305302285156aa1f71328ecac70377abdd92c80
Ref: nodejs/node#11865
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1273049
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56554}
2018-10-11 09:22:58 +00:00
Benedikt Meurer
0038e5f05f [async] Improve async function handling.
This change introduces new intrinsics used to desugar async functions
in the Parser and the BytecodeGenerator, namely we introduce a new
%_AsyncFunctionEnter intrinsic that constructs the generator object
for the async function (and in the future will also create the outer
promise for the async function). This generator object is internal
and never escapes to user code, plus since async functions don't have
a "prototype" property, we can just a single map here instead of tracking
the prototype/initial_map on every async function. This saves one word
per async function plus one initial_map per async function that was
invoked at least once.

We also introduce two new intrinsics %_AsyncFunctionReject, which
rejects the outer promise with the caught exception, and another
%_AsyncFunctionResolve, which resolves the outer promise with the
right hand side of the `return` statement. These functions also perform
the DevTools part of the job (aka popping from the promise stack and
sending the debug event). This allows us to get rid of the implicit
try-finally from async functions completely; because the finally
block only called to the %AsyncFunctionPromiseRelease builtin, which
was used to inform DevTools.

In essence we now turn an async function like

```js
async function f(x) { return await bar(x); }
```

into something like this (in Parser and BytecodeGenerator respectively):

```
function f(x) {
  .generator_object = %_AsyncFunctionEnter(.closure, this);
  .promise = %AsyncFunctionCreatePromise();
  try {
    .tmp = await bar(x);
    return %_AsyncFunctionResolve(.promise, .tmp);
  } catch (e) {
    return %_AsyncFunctionReject(.promise, e);
  }
}
```

Overall the bytecode for async functions gets significantly shorter
already (and will get even shorter once we put the outer promise into
the async function generator object). For example the bytecode for a
simple async function

```js
async function f(x) { return await x; }
```

goes from 175 bytes to 110 bytes (a ~38% reduction in size), which
is in particular due to the simplification around the try-finally
removal.

Overall this seems to improve the doxbee-async-es2017-native test by
around 2-3%. On the test case mentioned in v8:8276 we go from
1124ms to 441ms, which corresponds to a 60% reduction in total
execution time!

Tbr: marja@chromium.org
Bug: v8:7253, v8:7522, v8:8276
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4
Reviewed-on: https://chromium-review.googlesource.com/c/1269041
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56502}
2018-10-10 06:37:53 +00:00
Benedikt Meurer
8f8b5f8c6c [es2018] Consistently use AsyncReturnStatement in async functions.
The Parser desugaring didn't use the AsyncReturnStatement consistently
to return from async functions (aka resolve the .promise with the return
value and return the .promise from the async function). Instead the
Parser essentially had a copy of the BytecodeGenerator functionality.

This change unifies the handling of returns from async functions.

Bug: v8:7522, v8:8238
Change-Id: Ib00a60aee30d541b84835d9cc83e9937b7a39e26
Reviewed-on: https://chromium-review.googlesource.com/c/1269036
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56453}
2018-10-08 18:42:22 +00:00
Benedikt Meurer
1f0cd95278 [async] Initial async generator support for --async-stack-traces.
This forces .generator_object variable to stack slot 0 for async
generator functions so that the stack trace construction logic
can extract the JSAsyncGeneratorObject appropriately.

Bug: v8:7522
Change-Id: I37b52836bb512bcf5cd7e10e1738c8e7895b06ea
Ref: nodejs/node#11865
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1264556
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56415}
2018-10-05 13:41:53 +00:00
Benedikt Meurer
f537d77845 [async] First prototype of zero-cost async stack traces.
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: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56363}
2018-10-04 08:02:06 +00:00
Creddy
0714bd9fa0 Reland "[interpreter] Separate bytecodes for one-shot property loads and stores"
This is a reland of eccf186749

Original change's description:
> [interpreter] Separate bytecodes for one-shot property loads and stores
> 
> Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
> for one-shot property loads and stores. This CL replaces the runtime
> calls with new bytecodes for named property load stores in one-shot code.
> the runtime calls needed extra set of consecutive registers and
> additional move instructions. This increased the size of
> bytecode-array and possibly extended the life time of objects.
> By replacing them with NoFeedback bytecodes we avoid these issues.
> 
> Bug: v8:8072
> Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
> Reviewed-on: https://chromium-review.googlesource.com/1196725
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#56211}

Bug: v8:8072
Change-Id: Ie8e52b37daf35c7bc08bb910d7b15a9b783354e4
Reviewed-on: https://chromium-review.googlesource.com/1245742
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56266}
2018-09-27 13:56:53 +00:00
Maya Lekova
3c3330f6f0 Revert "[interpreter] Separate bytecodes for one-shot property loads and stores"
This reverts commit eccf186749.

Reason for revert: Speculative revert because it seems to introduce a pretty stable flake on gc stress tests, see https://bugs.chromium.org/p/v8/issues/detail?id=8229

Original change's description:
> [interpreter] Separate bytecodes for one-shot property loads and stores
> 
> Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
> for one-shot property loads and stores. This CL replaces the runtime
> calls with new bytecodes for named property load stores in one-shot code.
> the runtime calls needed extra set of consecutive registers and
> additional move instructions. This increased the size of
> bytecode-array and possibly extended the life time of objects.
> By replacing them with NoFeedback bytecodes we avoid these issues.
> 
> Bug: v8:8072
> Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
> Reviewed-on: https://chromium-review.googlesource.com/1196725
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#56211}

TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,neis@chromium.org,cbruni@chromium.org,chandanreddy@google.com

Change-Id: I445db58e6d4c275b434fabad5fad775bf259033f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8072
Reviewed-on: https://chromium-review.googlesource.com/1245421
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56232}
2018-09-26 08:36:14 +00:00
Creddy
eccf186749 [interpreter] Separate bytecodes for one-shot property loads and stores
Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
for one-shot property loads and stores. This CL replaces the runtime
calls with new bytecodes for named property load stores in one-shot code.
the runtime calls needed extra set of consecutive registers and
additional move instructions. This increased the size of
bytecode-array and possibly extended the life time of objects.
By replacing them with NoFeedback bytecodes we avoid these issues.

Bug: v8:8072
Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
Reviewed-on: https://chromium-review.googlesource.com/1196725
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#56211}
2018-09-25 13:53:53 +00:00
Benedikt Meurer
44c24bf827 [cleanup] Remove a lot of dead intrinsics/runtime functions.
The following runtime functions (and their intrinsic counter parts) are
completely unused/obsolete by now

  - %ToInteger
  - %GeneratorGetInputOrDebugPos

and in addition the intrinsics for %_ToNumber and %_IsJSProxy are also
dead (according to code coverage and manual verification), so drop them
as well (their runtime function counterparts are still somewhat used).

Bug: v8:8015
Change-Id: I60d53762dd9717fb43de38cb490b46676c467212
Reviewed-on: https://chromium-review.googlesource.com/1235923
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56076}
2018-09-20 12:48:57 +00:00
Dan Elphick
daa296b564 [interpreter] Always put bytecode handlers in builtins table
This always creates the bytecode handlers as part of the builtins table
regardless of the V8_EMBEDDED_BYTECODE_HANDLERS definition.

Lazy deserialization of bytecode handlers is enabled for this flow by
moving the three lazy bytecode deserializers from the strong roots into
the builtins table (ensuring that they not marked lazy themselves).

To simplify lazy deserialization, the illegal bytecode handler is made
non-lazy so that GetAndMaybeDeserializeBytecodeHandler doesn't to know
about it.

Since the bytecode handlers are now always part of the builtins table,
many bytecode specific methods are removed, including logging and in
BuiltinsSerializer and BuiltinsDeserializer.

Removes setup-interpreter.h, setup-interpreter-internal.cc and
builtin-snapshot-utils.*.

Change-Id: Ie421aa897a04f7b3bcb964c476eb7ab149388d53
Reviewed-on: https://chromium-review.googlesource.com/1220046
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56063}
2018-09-20 09:58:15 +00:00
Creddy
b2ed47b958 [interpreter] Restrict one-shot optimizations to only top-level IIFEs
IIFE`s within a function are not guaranteed to be executed only once.
They can be called multiple times and compiler can inline them.
Do the one-shot optimizations only for IIFE`s from top-level code.

Bug: v8:8072, chromium:886580
Change-Id: I02370681cc3eab270edcc75ee120ca7ad768ed52
Reviewed-on: https://chromium-review.googlesource.com/1231174
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56024}
2018-09-19 10:15:13 +00:00
Sathya Gunasekaran
1908872dcd [class] Make class field initializers breakable in the debugger
Add tests.

Bug: v8:5367
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I2a4215a87ba1dae98c4b25547494165f534b4a66
Reviewed-on: https://chromium-review.googlesource.com/1218046
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55974}
2018-09-17 22:25:44 +00:00
Creddy
aaab2907cc [Interpreter] Create and use CallNoFeedback bytecode for one-shot code
We do not have to collect feedback for function calls in one-shot code.
This CL avoids allocating CallICslots for each function call by
emitting CallNoFeedback bytecodes. We save one CallICSlot (two entries
in feedback vector) per function call in One-shot.

Bug: v8:8072
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ic2580e5972acd5124c2e71d540985736ce797fe8
Reviewed-on: https://chromium-review.googlesource.com/1178051
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55951}
2018-09-17 11:28:25 +00:00
Marja Hölttä
c696376e0b Reland [in-place weak refs] Fix MaybeObject function names
E.g., "ToWeakHeapObject" was misleading, since it didn't convert to a weak heap
object, instead returned a weakly pointed heap object. Change the function names
(in this case, to "GetHeapObjectIfWeak") to reflect this.

Also make casts explicit, if a MaybeObject is an Object, we can call cast<Object>().

Previous version: https://chromium-review.googlesource.com/1219025

BUG=v8:7308
TBR=ishell@chromium.org, ulan@chromium.org, ahaas@chromium.org, yangguo@chromium.org, tebbi@chromium.org

Change-Id: I503d4a2a3a68f85e9e02e1c2f9fc1c4187c8e9a1
Reviewed-on: https://chromium-review.googlesource.com/1226800
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55934}
2018-09-17 08:27:59 +00:00
Florian Sattler
0390eef826 [cleanup] Refactor interpreter to use default members.
Fixing clang-tidy warning.

Bug: v8:8015
Change-Id: I6cd63aa164af2e3b4a846933899a9a1baa54b1ef
Reviewed-on: https://chromium-review.googlesource.com/1224032
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Florian Sattler <sattlerf@google.com>
Cr-Commit-Position: refs/heads/master@{#55921}
2018-09-14 16:50:34 +00:00
Marja Hölttä
3a79fe2363 Revert "[in-place weak refs] Fix MaybeObject function names"
This reverts commit ad72d19516.

Reason for revert: Build failures on *san

Original change's description:
> [in-place weak refs] Fix MaybeObject function names
> 
> E.g., "ToWeakHeapObject" was misleading, since it didn't convert to a weak heap
> object, instead returned a weakly pointed heap object. Change the function names
> (in this case, to "GetHeapObjectIfWeak") to reflect this.
> 
> Also make casts explicit, if a MaybeObject is an Object, we can call cast<Object>().
> 
> BUG=v8:7308
> 
> Change-Id: I4ef078572b4f4415afe7e2e706d3bd684e16e47d
> Reviewed-on: https://chromium-review.googlesource.com/1219025
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55906}

TBR=ulan@chromium.org,marja@chromium.org,yangguo@chromium.org,ahaas@chromium.org,tebbi@chromium.org,ishell@chromium.org

Change-Id: I054b578518e3f6fd7dbcddf0b56cc018726c1e7a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7308
Reviewed-on: https://chromium-review.googlesource.com/1226874
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55918}
2018-09-14 15:30:05 +00:00
Marja Hölttä
ad72d19516 [in-place weak refs] Fix MaybeObject function names
E.g., "ToWeakHeapObject" was misleading, since it didn't convert to a weak heap
object, instead returned a weakly pointed heap object. Change the function names
(in this case, to "GetHeapObjectIfWeak") to reflect this.

Also make casts explicit, if a MaybeObject is an Object, we can call cast<Object>().

BUG=v8:7308

Change-Id: I4ef078572b4f4415afe7e2e706d3bd684e16e47d
Reviewed-on: https://chromium-review.googlesource.com/1219025
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55906}
2018-09-14 13:58:06 +00:00
Florian Sattler
b2dac95379 [cleanup] Replace 0 and NULL with nullptr for test files.
Fixing clang-tidy warning.

Bug: v8:8015
Change-Id: I2a7a8c8447d2835205f7a506f04efe4d1801b934
Reviewed-on: https://chromium-review.googlesource.com/1224316
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Florian Sattler <sattlerf@google.com>
Cr-Commit-Position: refs/heads/master@{#55903}
2018-09-14 12:56:00 +00:00
Florian Sattler
a8c2ad368d [cleanup] Refactor TestCaseData to use delete
Fixing clang-tidy warning.

Bug: v8:8015
Change-Id: I2ac8b12c040af2ad6122ce14eef8b4f8375e46ac
Reviewed-on: https://chromium-review.googlesource.com/1219708
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Florian Sattler <sattlerf@google.com>
Cr-Commit-Position: refs/heads/master@{#55814}
2018-09-12 07:54:35 +00:00
Creddy
f79caee25f [Runtime] Use Runtime_SetNamedProperty for property stores in one-shot code.
- Rename Runtime_SetProperty to Runtime_SetKeyedProperty
- Create Runtime_SetNamedProperty and use it for SetNamed property
  in one-shot code.
- Rename Object::StoreFromKeyed enum to StoreOrigin

Bug: v8:8072, chromium:876839
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I22132380ca4b6ce1e0a14a38cca849814559cdcf
Reviewed-on: https://chromium-review.googlesource.com/1207870
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#55790}
2018-09-11 13:42:25 +00:00
Hai Dang
5f8a42727d Reland "[interpreter] Add bytecode for leading array spreads."
This is a reland of 1c48d52bb1.

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: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55639}
2018-09-05 09:29:51 +00:00
Georg Neis
ef56902851 Revert "[interpreter] Add bytecode for leading array spreads."
This reverts commit 1c48d52bb1.

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/1199303
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55544}
2018-08-31 11:43:33 +00:00
Hai Dang
1c48d52bb1 [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}
2018-08-30 11:47:58 +00:00
Hai Dang
b2ceebbc25 Add helper class to share feedback slots.
The SharedFeedbackSlot helper class allow bytecodes to share one feedback
slot. The helper will only create the slot on-demand, at the first-use.
This does not encapsulate the use-case of FeedbackSlotCache.

Change-Id: I22aec19d59e52e7395898fa2a59c5c1ec95abbe8
Reviewed-on: https://chromium-review.googlesource.com/1189904
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55452}
2018-08-28 12:07:11 +00:00
Creddy
365e241780 [interpreter][runtime] Avoid AllocationSites for Array literals in oneshot code
No need to create allocation site for array literals in oneshot code since
they are executed only once. The interpreter emits a runtime call to
CreateArrayLiteralWithoutAllocationSite for creating literals in
oneshot code instead.

Change-Id: I285879c84759ff9e2ce281e9548112f52ce5e7d1
Reviewed-on: https://chromium-review.googlesource.com/1167843
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#55349}
2018-08-23 12:00:43 +00:00
Hai Dang
f30b43ed95 Add bytecode generation tests for array spreads.
Bug: v8:7973
Change-Id: I44ad457c3a103c36bd7b928cc64a056c1a1afc46
Reviewed-on: https://chromium-review.googlesource.com/1183102
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#55257}
2018-08-21 10:51:51 +00:00
Creddy
ec8700c418 [interpreter][runtime] Avoid AllocationSites for oneshot code
No need to create allocation site for literals in oneshot code since
they are executed only once. The interpreter emits a runtime call to
CreateObjectLiteralWithoutAllocationSite for creating literals in
oneshot code instead.

Change-Id: I224b3a30f10361cfe9ff63129b36da8230c5e403
Reviewed-on: https://chromium-review.googlesource.com/1163615
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55050}
2018-08-10 13:34:13 +00:00
jgruber
3c1f40de25 [builtins] Fix argument order inconsistency in HasProperty
The HasProperty builtin differed in its expected argument order from
the HasProperty runtime function. Like all other related spec
primitives (e.g.: GetProperty, SetProperty, DeleteProperty), it should
take {object} as the first argument and {key} as the second.

This CL changes the builtin and all related spots to use the correct
order.

There was also a tricky bug in interpreter intrinsic rewriting, which
assumes (but does not verify) that the argument order between runtime
function and builtin is identical. Besides cctests, HasProperty
intrinsic rewriting seems to be dead code.

Bug: v8:8036
Change-Id: Ia669fd6f5c73a30df4e4607064603be759ced392
Reviewed-on: https://chromium-review.googlesource.com/1167297
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55022}
2018-08-09 12:30:27 +00:00
Creddy
3b2b858f11 Reland "[Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code"
This is a reland of 690bda84eb

Original change's description:
> [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code
> 
> An IIFE or top-level code is executed only once hence, there is no need to collect
> type feedback. We can save some memory by not using IC slots for property Loads/Stores
> within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty
> /StaNamedProperty for the property loads within a IIFE and top-level code.
> 
> Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9
> Reviewed-on: https://chromium-review.googlesource.com/1146579
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#54949}

Change-Id: I7b07ce86f7236d82191caaceafd31b86e5863ff5
Reviewed-on: https://chromium-review.googlesource.com/1167802
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#55017}
2018-08-09 10:47:38 +00:00
Frank Tang
b27c3736c1 [Intl] Implement Intl.ListFromat format() and formatToParts().
Spec: http://tc39.github.io/proposal-intl-list-format/

Design Doc:  go/add-intl.listformat-to-v8

Test: intl/list-format/*

R=gsathya@chromium.org, mvstanton@chromium.org

Bug: v8:7871
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I820c205ca842c228ffe37f7e1648667f30f80bd8
Reviewed-on: https://chromium-review.googlesource.com/1126683
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54991}
2018-08-08 23:52:27 +00:00
Michael Achenbach
247e179ca7 Revert "[Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code"
This reverts commit 690bda84eb.

Reason for revert: Speculative revert for:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/25372

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

Original change's description:
> [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code
> 
> An IIFE or top-level code is executed only once hence, there is no need to collect
> type feedback. We can save some memory by not using IC slots for property Loads/Stores
> within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty
> /StaNamedProperty for the property loads within a IIFE and top-level code.
> 
> Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9
> Reviewed-on: https://chromium-review.googlesource.com/1146579
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#54949}

TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,yangguo@chromium.org,cbruni@chromium.org,leszeks@chromium.org,verwaest@chromium.org,chandanreddy@google.com

Change-Id: I642164a72453189fd0fe92b69f199f958ce56bef
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/1166782
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54955}
2018-08-08 06:39:55 +00:00
Creddy
690bda84eb [Interpreter] Do not use IC slots for property load/stores in an IIFE and top-level code
An IIFE or top-level code is executed only once hence, there is no need to collect
type feedback. We can save some memory by not using IC slots for property Loads/Stores
within a IIFE/top-level code. This CL emits Runtime Get/Set property calls instead of LdaNamedProperty
/StaNamedProperty for the property loads within a IIFE and top-level code.

Change-Id: I3e0ce26d05d82bb3648cb9262c4e112a2c4556c9
Reviewed-on: https://chromium-review.googlesource.com/1146579
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#54949}
2018-08-07 14:58:43 +00:00
Sathya Gunasekaran
0af7b0d6ea [Intl] Clean up error handling
- Return empty handles instead of exceptions.
- Handlify functions instead of returning raw pointers.

Bug: v8:5751
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I28b018e5bdcaa375748eb04e9a6fed8cf64a5b05
Reviewed-on: https://chromium-review.googlesource.com/1148301
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54675}
2018-07-25 07:45:04 +00:00
Stephan Herhut
6d25cab2c8 [cleanup] Split off api-inl.h from api.h to make latter self contained
api.h had an implicit dependency on objects-inl.h.

Bug: v8:7490
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I56ef7abefed7205bdbff2aa5f451f1a843bef9f9
Reviewed-on: https://chromium-review.googlesource.com/1145191
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54616}
2018-07-23 16:03:49 +00:00
Frank Tang
b819afeb4f [Intl] Implement Intl.RelativeTimeFormat.prototype.{format, formatToParts}
Spec: http://tc39.github.io/proposal-intl-relative-time/

Design Doc: go/add-intl.relativetimeformat-to-v8

Test: test262/intl402/RelativeTimeFormat/*, intl/relative-time-format/*

R=cira@chromium.org, gsathya@chromium.org

Bug: v8:7869
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ied95d601cf707db5d555f9d963b9b1f206e37331
Reviewed-on: https://chromium-review.googlesource.com/1124728
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54520}
2018-07-18 12:49:22 +00:00
Dan Elphick
55a348ceb4 [explicit isolates] Remove various GetIsolates
Ran GetIsolate/GetHeap removal script over all the header files included
into objects.cc. Affected classes include: ScriptContextTable
RuntimeCallTimerScope GlobalDictionaryShape Map LookupIterator
PrototypeIterator FixedArrayBuilder

Manually fixed up Map to mark its write operations as safe for
GetIsolate since they modify the object as so can't be done in RO_SPACE.

Bug: v8:7786
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I2fd0960f085d1bcb4cf54b3418899ac0217917ca
Reviewed-on: https://chromium-review.googlesource.com/1138076
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54488}
2018-07-17 11:56:37 +00:00
Frank Tang
97cdf44d7c [Intl] Implement Intl.RelativeTimeFormat constructor
Spec: http://tc39.github.io/proposal-intl-relative-time/

Design Doc: go/add-intl.relativetimeformat-to-v8

Test: test262/intl402/RelativeTimeFormat/*, intl/relative-time-format/*

R=gsathya@chromium.org, mstarzinger@chromium.org

Bug: v8:7869
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I2cfe8dba9d3a99957ad4b444023c89bbdae08c7c
Reviewed-on: https://chromium-review.googlesource.com/1124121
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54358}
2018-07-10 14:20:06 +00:00
Creddy
bb0975878f [runtime][parser] Use ArrayBoilerplateDescription all the way
* Rename BoilerplateDescription to ObjectBoilerplateDescription
* Add literal_type flag to ObjectBoilerplateDescription,
  which is stored as zeroth element of Fixed array
* Create ArrayBoilerplateDescription with elements_kind and
  constant_elements field
* Replace CompileTimeValue and ConstantElementPair with
  ArrayBoilerplateDescription
* Kill ConstantElementPair and CompileTimeValue

Change-Id: Icb42dcfd575a27e2b64ffd5e2e61f9d703d5e986
Bug: v8:7787, chromium:818642
Reviewed-on: https://chromium-review.googlesource.com/1122411
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54272}
2018-07-05 19:31:03 +00:00
Leszek Swirski
155c34d185 [GetIsolate] Remove GetIsolate from src/objects/*
Bug: v8:7786
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: If9904fe8feb9b4e157d42d6e84f1aa263abcc8b7
Reviewed-on: https://chromium-review.googlesource.com/1106160
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53882}
2018-06-20 12:46:22 +00:00
Alexey Kozyatinskiy
0b690227f8 Reland "[inspector] fixed location of top level function return"
This is a reland of 4363a69335

Original change's description:
> [inspector] fixed location of top level function return
>
> We should pass false as has_braces argument to create FunctionLiteral
> for top level function.
>
> R=dgozman@chromium.org,bmeurer@chromium.org
> TBR=bmeurer@chromium.org
>
> Bug: none
> Change-Id: I397f31b562d32c71f3a12bfc9ceeed16c367aa80
> Reviewed-on: https://chromium-review.googlesource.com/1098018
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53769}
TBR=dgozman@chromium.org

Bug: v8:7858
Change-Id: Ie636bc101f9d29d9d40bd10b96e62da6505c2734
Reviewed-on: https://chromium-review.googlesource.com/1104497
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53808}
2018-06-18 21:37:49 +00:00
Clemens Hammacher
7a8e24b48f Revert "[inspector] fixed location of top level function return"
This reverts commit 4363a69335.

Reason for revert: Seems to break layout tests: https://ci.chromium.org/buildbot/client.v8.fyi/V8-Blink%20Linux%2064/24146

Original change's description:
> [inspector] fixed location of top level function return
> 
> We should pass false as has_braces argument to create FunctionLiteral
> for top level function.
> 
> R=​dgozman@chromium.org,bmeurer@chromium.org
> TBR=bmeurer@chromium.org
> 
> Bug: none
> Change-Id: I397f31b562d32c71f3a12bfc9ceeed16c367aa80
> Reviewed-on: https://chromium-review.googlesource.com/1098018
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53769}

TBR=dgozman@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org

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

Bug: none
Change-Id: I4495f6723daed63b7a38b0d3c3637724f6c2d484
Reviewed-on: https://chromium-review.googlesource.com/1104017
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53775}
2018-06-18 07:59:39 +00:00
Alexey Kozyatinskiy
4363a69335 [inspector] fixed location of top level function return
We should pass false as has_braces argument to create FunctionLiteral
for top level function.

R=dgozman@chromium.org,bmeurer@chromium.org
TBR=bmeurer@chromium.org

Bug: none
Change-Id: I397f31b562d32c71f3a12bfc9ceeed16c367aa80
Reviewed-on: https://chromium-review.googlesource.com/1098018
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53769}
2018-06-15 15:11:27 +00:00
Leszek Swirski
d6c49a7251 [GetIsolate] Remove GetIsolate in simple cases
Whenever an Isolate is available on a variable, field, or method
parameter, use that instead of GetIsolate(). Also convert simple
cases of the one-argument handle constructor to either use an
available Isolate, or use GetIsolate() if their first parameter
is a variable.

Bug: v8:7786
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I52805905a9ca8729615ead78859f43d5e8f605f1
Reviewed-on: https://chromium-review.googlesource.com/1092853
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53629}
2018-06-11 11:02:59 +00:00
Mythri
9461aa5619 [Interpreter] Enable sharing of load / store named property feedback
This cl enables sharing of feedback slots for load / sotre named property.
This is a follow up cl of
https://chromium-review.googlesource.com/c/v8/v8/+/966302 that introduces
this feature.

Bug: v8:7530
Change-Id: I0c056b7a3608117db2fc99ebcd6836dfeed471d8
Reviewed-on: https://chromium-review.googlesource.com/1065737
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53515}
2018-06-05 09:21:59 +00:00
Alexey Kozyatinskiy
b6c9086ca1 [inspector] reworked async stack instrumentation for async functions
New intstrumentation consists of:
- kAsyncFunctionSuspended when async function is suspended on await
  (called on each await),
- kAsyncFunctionFinished when async function is finished.

Old instrumentation was based on reusing async function promise.
Using this promise produces couple side effects:
- for any promise instrumentation we first need to check if it is
  special case for async function promise or not - it requires
  expensive reading from promise object.
- we capture stack for async functions even if it does not contain
  awaits.
- we do not properly cancel async task created for async function.

New intsrumntation resolved all these problems as well as provide
clear mapping between async task and generator which we can use later
to fetch scope information for async functions on pause.

R=dgozman@chromium.org,yangguo@chromium.org

Bug: v8:7078
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ifdcec947d91e6e3d4d5f9029bc080a19b8e23d41
Reviewed-on: https://chromium-review.googlesource.com/1043096
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53445}
2018-05-30 16:01:59 +00:00
Dan Elphick
ff9263f80c [objects] Make Object::BooleanValue take an Isolate
Removes use of HeapObject::GetIsolate() from Object::BooleanValue in
preparation for removing the method.

Requires adding Isolate parameter to CommonOperatorReducer constructor.

Bug: v8:7786
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: If735e71df3288bf1eb11576605c2d95a19472181
Reviewed-on: https://chromium-review.googlesource.com/1071653
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53361}
2018-05-25 14:37:22 +00:00
Marja Hölttä
71e4c57319 [objects.h splitting] Move TYPE_CHECKERs back to objects-inl.h.
Moving them away was a mistake. Fixing this enables getting rid of a bunch of
includes.

BUG=v8:5402

Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I5482eab4281c7450350f058fe0a04a6f375ea082
Reviewed-on: https://chromium-review.googlesource.com/1070188
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53328}
2018-05-24 11:44:07 +00:00
Jaroslav Sevcik
ea7499f5da [generators] Store parameters in the generator object.
Currently, we context allocate all parameters for generators.

With this CL, we keep arguments on stack (unless they escape to inner
closure) and copy them between the stack and the generator's register
file on suspend/resume. This will save context allocation in most cases.

Note: There is an asymmetry between suspend and resume.
- Suspend copies arguments and registers to the generator.
- Resume copies only the registers from the generator, the arguments
  are copied by the ResumeGenerator trampoline.

Bug: v8:5164
Change-Id: I6333898c60abf461b1ab1b5c6d3dc7188fa95649
Reviewed-on: https://chromium-review.googlesource.com/1063712
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53327}
2018-05-24 11:41:37 +00:00
Nebojsa Ciric
ab72273692 Implementing Intl.Locale proposal.
https://github.com/tc39/proposal-intl-locale

Rename locale property to baseName to better reflect the intented use case and the change in spec.

TBR: bmeurer@chromium.org
Bug: v8:7684
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I91b630b49ce73abcebd6040ec968c91d75cff879
Reviewed-on: https://chromium-review.googlesource.com/1014411
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53193}
2018-05-15 22:25:02 +00:00
Mythri
a55117d7ed [Interpreter] Share feedback slots for load / store named properties
Shares the feedback slot when loading / storing named properties
when the name of the property and the variable corresponding
to the object are the same. This reduces the memory usage on most
real world benchmarks. There is a slight (~1%) increase in the overall
time spent in V8 on a couple of these pages.

There is also no overall performance regression on peak-performance
benchmarks like Octane, ARES. More detailed results are in this doc[1]

[1]: https://docs.google.com/document/d/1rPNjXU-WOlyNQovuQS28Zf2PHCENR97Bi76gV9mHHOc/edit?usp=sharing

BUG: v8:7530
Change-Id: I7dd98c2d26f4e6c94690ca7d9a8a4a8281b3142d
Reviewed-on: https://chromium-review.googlesource.com/966302
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53145}
2018-05-14 10:21:42 +00:00
Maya Lekova
91ddb65d3b Revert promises optimizations due to regressions in async hooks
Revert "[async-await] Eliminate throwaway promise in async functions."

This reverts commit a840f1f8f7.

Revert "[async-generators] Also avoid throwaway promise here."

This reverts commit feb545ceba.

Revert "[async-await] Turn await closures into intrinsics."

This reverts commit d97bb31738.

Revert "[async-generators] Add fast-path for primitives in AsyncGeneratorYield."

This reverts commit e57b500eb2.

Revert "[async-generators] Add fast-path to skip "then" lookup in AsyncGeneratorResolve."

This reverts commit c15802e11e.

Revert "[promises] Correctly run before/after hooks for await."

This reverts commit ca7639239f.

Bug: v8:7253, v8:7745
Change-Id: I25ad0d2df3cfbc84dbb431aa25b268bce8a39e89
Reviewed-on: https://chromium-review.googlesource.com/1049975
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53139}
2018-05-14 09:36:22 +00:00
Marja Hölttä
33157f3de7 [in-place weak refs] Replace the WeakCell(transition_map) in FeedbackVector.
- Make FeedbackVector backing store a WeakFixedArray.
- "feedback" is always strong but "extra" might be weak.
- Whenever the handler stored in FeedbackVector is a WeakCell to a transition
  Map, replace it with an in-place weak reference.
For a more detailed description of the changes, see the design doc

https://docs.google.com/document/d/1P8cIme2wKszdYt64ObAiuh6pXgLnrrn80Hpl1ejJbOU/edit#heading=h.ijx1oculrikp

BUG=v8:7308

Change-Id: I72c5cf6597ef24d4c22a1fe8e25b67ca196d4ec8
Reviewed-on: https://chromium-review.googlesource.com/1027855
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53051}
2018-05-08 08:08:26 +00:00
Toon Verwaest
0f7721719d Remove the catch variable name from the extension field of catch contexts
Instead rely on the scope info containing the name as well.

Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab
Reviewed-on: https://chromium-review.googlesource.com/1042567
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52983}
2018-05-04 10:12:08 +00:00
Toon Verwaest
39496a95c5 Replace Context::closure with Context::scope_info, allowing closure to die.
There are likely cleanups that can be done after this CL:
- context-related functions in the interpreter and compiler take ScopeInfo as
well as ScopeType and slot-count as input. The latter 2 should be directly
derived from the former. We should be able to drop FunctionContextParameters.
- ContextExtension is probably not needed anymore, since we now always have the
correct scope_info directly in the SCOPE_INFO_INDEX slot.

Bug: v8:7066
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67
Reviewed-on: https://chromium-review.googlesource.com/785151
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52952}
2018-05-03 12:34:17 +00:00
Leszek Swirski
18bc285621 Revert "[parser] Slice the source string where possible"
This reverts commit 2df5e7a7b6.

Reason for revert: Mystery crashes https://bugs.chromium.org/p/chromium/issues/detail?id=838805

Original change's description:
> [parser] Slice the source string where possible
> 
> When internalizing string literals (for quoted strings or property names),
> try to create a sliced string of the source string rather than allocating
> a copy of the bytes.
> 
> This will not work for string literals that contain escapes (e.g. unicode
> escapes), and currently does not support two-byte strings.
> 
> Bug: chromium:818642
> Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
> Reviewed-on: https://chromium-review.googlesource.com/1010282
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52898}

TBR=marja@chromium.org,yangguo@chromium.org,jarin@chromium.org,mlippautz@chromium.org,leszeks@chromium.org,verwaest@chromium.org

Change-Id: I598b6668c43a3e843e2dd8e60852b2b2f3461954
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:818642
Reviewed-on: https://chromium-review.googlesource.com/1039885
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52919}
2018-05-02 15:32:13 +00:00
Leszek Swirski
2df5e7a7b6 [parser] Slice the source string where possible
When internalizing string literals (for quoted strings or property names),
try to create a sliced string of the source string rather than allocating
a copy of the bytes.

This will not work for string literals that contain escapes (e.g. unicode
escapes), and currently does not support two-byte strings.

Bug: chromium:818642
Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
Reviewed-on: https://chromium-review.googlesource.com/1010282
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52898}
2018-05-01 15:38:19 +00:00
Georg Neis
021e9b089e Remove incorrect receiver checks from some array methods.
Several functions on Array.prototype incorrectly threw a TypeError just
because their receiver was sealed or frozen.

Bug: v8:7677
Change-Id: I4ec38bfbf468f9bd676f1c0b341c8a50cf814f15
Reviewed-on: https://chromium-review.googlesource.com/1021870
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52718}
2018-04-23 08:57:35 +00:00
Christian O. Andersson
894b95fe38 [ignition] Optimizing Smi only comparisons
There are various situations where we explicitly compare a SMI against
another SMI (e.g., BuildIndexedJump). This is also a common pattern for
generated code (e.g., comparing a loop variable with an integer). Instead
of using the generic equality/strict-equality stub for this, which is
expensive, this CL offers a simple comparison stub, repurposing the
TestEqualStrictNoFeedback bytecode to TestReferenceEqual

Bug: v8:5310
Change-Id: Ib2b47cd24d5386cf0d20d3bd794776dc6e3a02a5
Reviewed-on: https://chromium-review.googlesource.com/1007542
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Christian O. Andersson <cricke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52655}
2018-04-18 04:54:54 +00:00
Sathya Gunasekaran
eb4ebf98c9 [class] Initialize class fields after binding this
Class fields needs to be initialized after `this` is bound, as per the
new spec change:
https://github.com/tc39/proposal-class-fields/pull/92

This CL moves the initialization of `this` from parser desugaring to
the bytecode generator.

Bug: v8:7647
Change-Id: I20f749403e5a4d2f06a39726cf39012ceb541987
Reviewed-on: https://chromium-review.googlesource.com/1014383
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52646}
2018-04-17 13:40:39 +00:00
Jakob Kummerow
2459046c1d [ubsan] Change Address typedef to uintptr_t
The "Address" type is V8's general-purpose type for manipulating memory
addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
are undefined behavior except within the same array; since we generally
don't operate within a C++ array, our general-purpose type shouldn't be
a pointer type.

Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
Reviewed-on: https://chromium-review.googlesource.com/988657
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52601}
2018-04-14 01:25:28 +00:00
Georg Neis
42049b43c9 [interpreter] Move desugaring of spread super call to bytecode generator
This patch moves the desugaring from the parser to the bytecode
generator for super calls that have a spread at a non last position.

This allows us to have the post super() call behavior, such as
initializing instance fields in one place in VisitCallSuper.

Bug: v8:7642
Change-Id: I00a693beb7078a63282359c1121b66bb62c157c8
Reviewed-on: https://chromium-review.googlesource.com/1009907
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52596}
2018-04-13 18:25:31 +00:00
Matheus Marchini
ada64b58bf interpreter: make interpreted frames distinguishable in the native stack
Before Turbofan/Ignition it was possible to use external profilers to
sample running V8/Node.js processes and generate reports/FlameGraphs
from that. It's still possible to do so, but non-optimized JavaScript
functions appear in the stack as InterpreterEntryTrampoline. This commit
adds a runtime flag which makes interpreted frames visible on the
process' native stack as distinguishable functions, making the sampled
data gathered by external profilers such as Linux perf and DTrace more
useful.

R=bmeurer@google.com, franzih@google.com, jarin@google.com, yangguo@google.com

Bug: v8:7155
Change-Id: I3dc8876aa3cd9f1b9766624842a7cc354ccca415
Reviewed-on: https://chromium-review.googlesource.com/959081
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52533}
2018-04-10 19:33:55 +00:00
Leszek Swirski
6bd1d3c280 [objects] Merge SFI outer_scope_info and feedback_metadata
Merge the outer_scope_info and feedback_metadata fields on
SharedFunctionInfo. outer_scope_info is only used during parsing,
and feedback_metadata is only available after compilation, so the
two never exist at the same time. Thus, they can share a field slot.

The exception is un-compiling and re-compiling a function, where we
need the outer_scope_info again. Fortunately, the outer_scope_info
can be re-calculated from the SFI's scope_info.

Bug: v8:7606
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I6b97fefe859e89df75ad870da4a0bfa4b869772a
Reviewed-on: https://chromium-review.googlesource.com/992432
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52454}
2018-04-06 15:06:04 +00:00
Igor Sheludko
f52d005395 [iterpreter] Share feedback slots for global stores to the same variable.
Bug: v8:7206, chromium:576312
Change-Id: I1628e7966a40fa7d6f628bd972b0ad0142a5d349
Reviewed-on: https://chromium-review.googlesource.com/970825
Reviewed-by: Mythri Alle <mythria@google.com>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52075}
2018-03-20 17:05:38 +00:00
Igor Sheludko
0fa0b28a84 [runtime] Remove unused Runtime::kDeclareGlobals.
... and rename Runtime::kDeclareGlobalsForInterpreter -> Runtime::kDeclareGlobals.

Bug: v8:7310
Change-Id: I58f9615b6948b66727f2de7e9ba1b0be4f87d9aa
Reviewed-on: https://chromium-review.googlesource.com/966291
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52038}
2018-03-19 15:14:24 +00:00
Mathias Bynens
697d39abff [esnext] Implement Array.prototype.{flatten,flatMap} 🥙
Proposal repo: https://tc39.github.io/proposal-flatMap/

Bug: v8:7220
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I61661fc6d5c39d084ce5c96a9e150e5c26799e2d
Also-By: bmeurer@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/957043
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51967}
2018-03-15 17:26:12 +00:00
Sathya Gunasekaran
acae2f2b65 [ignition] Set correct expression position for ObjectLiteral keys/values
Given the following input,
  const config = {
    min: Math.min(1, 2),
    func: myfunc(),
  }

Previously, the error was,
  ➜ ./out.gn/x64.release/d8 _test.js
  _test.js:3: ReferenceError: myfunc is not defined
    min: Math.min(1, 2),
              ^
  ReferenceError: myfunc is not defined
      at _test.js:3:13

Now, the error is,
  ➜ ./out.gn/x64.release/d8 _test.js
  _test.js:4: ReferenceError: myfunc is not defined
    func: myfunc(),
          ^
  ReferenceError: myfunc is not defined
      at _test.js:4:9

Bug: v8:7507
Change-Id: Ia65b445fdbc1369ecce80f4fc2040e500c807d40
Reviewed-on: https://chromium-review.googlesource.com/964182
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51964}
2018-03-15 15:36:41 +00:00
Caitlin Potter
b8229612bf Reland "[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

[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/958408
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#51933}
2018-03-14 18:12:09 +00:00
Benedikt Meurer
f269570290 [cleanup] Drop spread.js for good.
Use IteratorToList to implement CallWithSpread and ConstructWithSpread
instead.

Bug: v8:7310
Change-Id: Ic1c44cc97914fa4fb92da8c568ac66f3ae78e520
Reviewed-on: https://chromium-review.googlesource.com/956073
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51871}
2018-03-12 09:44:11 +00:00
Michael Achenbach
b8128279a3 Revert "[esnext] re-implement template strings"
This reverts commit 8ae19e08b1.

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/958163
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51862}
2018-03-10 16:45:30 +00:00
Caitlin Potter
8ae19e08b1 [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}
2018-03-09 18:14:07 +00:00
Caitlin Potter
470db43c7b [cctest] add bytecode generator tests for template literals
Just copies the StringConcat tests and refactors them to exercise
template literals rather than simple string addition.

BUG=v8:7415
R=rmcilroy@chromium.org

Change-Id: I79cf24ee33e64b1d57221eb0291d9958634130ec
Reviewed-on: https://chromium-review.googlesource.com/951968
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#51788}
2018-03-07 15:17:32 +00:00
Georg Neis
cf8cd1c444 [interpreter] Only create spread-related feedback slots when necessary.
Only create spread-related feedback slots when the array literal
actually contains a spread.

Bug: v8:5940
Change-Id: I0afad81d4bf1a86ebc1bf81f1213f680eb22bc49
Reviewed-on: https://chromium-review.googlesource.com/947955
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51721}
2018-03-05 11:01:32 +00:00
Georg Neis
2e2860f74f [ic] Introduce new IC for storing into array literals.
... 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: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51709}
2018-03-02 21:12:57 +00:00
Camillo Bruni
1f307ba52f [runtime] Add BOILERPLATE_DESCRIPTION_TYPE InstanceType
Bug: v8:7266
Change-Id: I2835ec79aaa2821aca288685a3f230a7f8029186
Reviewed-on: https://chromium-review.googlesource.com/941948
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51696}
2018-03-02 13:43:27 +00:00
Georg Neis
82345e9fbf Reland "[parsing] inline ArrayLiteral creation for spread calls"
This reverts commit f48e734903.

Reason for revert: innocent!!

Original change's description:
> Revert "[parsing] inline ArrayLiteral creation for spread calls"
> 
> This reverts commit 93fc3841c3.
> 
> 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/945808
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51686}
2018-03-02 10:03:42 +00:00
Sigurd Schneider
f48e734903 Revert "[parsing] inline ArrayLiteral creation for spread calls"
This reverts commit 93fc3841c3.

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}
2018-03-02 09:29:32 +00:00
Caitlin Potter
93fc3841c3 [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}
2018-03-02 08:44:26 +00:00
Michael Starzinger
fafd1cdd35 Move exception handler table into instruction stream.
This changes the encoding of the {HandlerTable} from an array of Smi
values to a byte array. It allows embedding of said array into the
instruction stream of {Code} objects (similar to how safepoint tables
work). For interpreted bytecode the table is attached as a {ByteArray}
to the bytecode.

The advantage of this approach is a more compact encoding and also the
ability to move such tables easily off the GC'ed heap if needed (as is
done for WebAssembly code for example).

R=jarin@chromium.org

Change-Id: I3320415dff69b3d1053825bda0d667a28232bf6d
Reviewed-on: https://chromium-review.googlesource.com/934642
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51589}
2018-02-27 10:20:35 +00:00
Sathya Gunasekaran
47abe102c3 [class] Add bytecode expectations test for private class fields
Bug: v8:5368
Change-Id: I7ec4bb6c0f50d8a72a12f5d4521c5fdcba526014
Reviewed-on: https://chromium-review.googlesource.com/929876
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51479}
2018-02-22 17:34:55 +00:00
Benedikt Meurer
aff1f3788b [cleanup] Introduce a dedicated FeedbackCell.
This is preparatory cleanup work for eventually tracking the functions
(rather than concrete closures) in the CALL_IC, also for builtins like
the default PromiseCapability [[Resolve]] and [[Reject]] functions. It
adds a new FeedbackCell type, which is used by JSFunctions consistently
now to reference the feedback vector (or undefined if not the function
is not compiled yet or is a native/asm.js function).

This also changes the calling convention for FastNewClosure builtin and
the JSCreateClosure operator in TurboFan to carry the FeedbackCell here
instead of the parent FeedbackVector and the slot index. In addition we
eliminate the now unused %InterpreterNewClosure runtime function.

Bug: v8:2206, v8:7253, v8:7310
Change-Id: Ib4ce456e276e0273e57c163dcdd0b33abf863656
Reviewed-on: https://chromium-review.googlesource.com/928403
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51474}
2018-02-22 13:18:48 +00:00
Sathya Gunasekaran
3cdb96b0ac [class] Ban private field deletion
Bug: v8:5368
Change-Id: I7c4f9101837a0bf4917bbb0c2f09587118168a02
Reviewed-on: https://chromium-review.googlesource.com/923362
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51449}
2018-02-21 19:14:23 +00:00
Benedikt Meurer
d97bb31738 [async-await] Turn await closures into intrinsics.
There's no need to have the AsyncFunctionAwait/AsyncGeneratorAwait
operations as separate closures that are called via JavaScript calling
convention, but instead we can just have them as intrinsics (with the
goal to eventually turn them into IC stubs).

Drive-by-fix: Tail call to the ResumeGenerator builtin when resuming
an async function. The earlier restrictions no only apply with the new
machinery.

Bug: v8:7253
Change-Id: I0c4d04dae15b4211158fc07151adafda69d4faec
Reviewed-on: https://chromium-review.googlesource.com/924703
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51382}
2018-02-20 06:39:01 +00:00
Camillo Bruni
8255eeb936 [runtime] Add SCOPE_INFO_TYPE InstanceType
Bug: v8:7310
Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012
Reviewed-on: https://chromium-review.googlesource.com/921742
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 13:42:05 +00:00
Toon Verwaest
313e33a709 Remove %_ClassOf and SharedFunctionInfo::instance_class_name
instance_class_name takes up space unnecessarily, and %_ClassOf and
class_name implement [[Class]] which isn't part of ES2015+ anymore.

Bug: 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3a73f732ad83a616817fde9992f4e4d584638fa8
Reviewed-on: https://chromium-review.googlesource.com/776683
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51309}
2018-02-15 11:52:08 +00:00
Benedikt Meurer
c041296189 [builtins] Refactor the promise resolution and rejection logic.
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/911632
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51260}
2018-02-13 04:18:12 +00:00
Peter Marshall
cf9b487355 [typedarray] Port ConstructByIterable by CSA.
This is the last piece of the TypedArray constructors that was still
written in JS.

Bug: v8:7102
Change-Id: I7c4dc867b09408caa4eec2873ea7185b6c61a525
Reviewed-on: https://chromium-review.googlesource.com/888751
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51122}
2018-02-06 17:06:43 +00:00
Leszek Swirski
71f758a2e2 [ignition] Reduce generator switch boilerplate
The SwitchOnGeneratorState bytecode now also falls through if the
generator object is undefined (so that we don't need that jump) and
restores generator context (so that we don't need that PushContext).
This saves 10 bytes per generator.

Change-Id: Ie0872c827119b9f1d1e9244d3be6496a30cd9620
Reviewed-on: https://chromium-review.googlesource.com/867051
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50845}
2018-01-24 17:09:54 +00:00
Leszek Swirski
d7fda25256 [ignition] Move suspend_id assignment to bytecode generation
Instead of building suspend_ids in the AST numbering, collect suspend
counts in the parser and assigning suspend ids during bytecode
generation.

Bug: v8:7178
Change-Id: I53421442afddc894db789fb9d0d3e3cc10e32ff0
Reviewed-on: https://chromium-review.googlesource.com/817598
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50830}
2018-01-24 12:02:09 +00:00
Leszek Swirski
c869d40d5a [ignition] Single-switch generator bytecode
Currently, yields and awaits inside loops compile to bytecode which
switches to the top of the loop header, and switch again once inside the
loop. This is to make loops reducible.

This replaces this switching logic with a single switch bytecode that
directly jumps to the bytecode being resumed. Among other things, this
allows us to no longer maintain the generator state after the switch at
the top of the function, and avoid having to track loop suspend counts.

TurboFan still needs to have reducible loops, so we now insert loop
header switches during bytecode graph building, for suspends that are
discovered to be inside loops during bytecode analysis. We do, however,
do some environment magic across loop headers since we know that we will
continue switching if and only if we reached that loop header via a
generator resume. This allows us to generate fewer phis and tighten
liveness.

Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385
Reviewed-on: https://chromium-review.googlesource.com/866734
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50804}
2018-01-23 14:27:02 +00:00
Leszek Swirski
5cef3ddd5f [ignition] Make SuspendGenerator return
Instead of requiring the pattern that a SuspendGenerator must be
followed by a Return, make SuspendGenerator return directly. This can,
in the future, simplify some of the reasoning around generator suspends.

Change-Id: I94c0156a89dc0e1c0bc306bc57acf766f3b4deb5
Reviewed-on: https://chromium-review.googlesource.com/857463
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50748}
2018-01-22 10:42:49 +00:00
Adam Klein
49898aad76 Remove always-true --harmony-async-iteration runtime flag
It was shipped in Chrome 63.

Bug: v8:5855
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icc00b8300622d1c7b5662be8ac5e425b9781f666
Reviewed-on: https://chromium-review.googlesource.com/858381
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50558}
2018-01-12 20:14:34 +00:00
Caitlin Potter
2d889aa9a4 Reland "[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
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: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50518}
2018-01-11 20:27:13 +00:00
Leszek Swirski
713eb9e765 [ignition] Change RestoreGeneratorRegisters to ResumeGenerator
This makes RestoreGeneratorRegisters do a fuller resume process: update
the state register to indicate that it is now executing, and update the
accumulator with the input_or_debug_pos of the generator - i.e., perform
the boilerplate generator resuming in one bytecode instead of several.

Change-Id: Ia87b6766ac023064b40d3e9a143e7b32118ea3a0
Reviewed-on: https://chromium-review.googlesource.com/859770
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50499}
2018-01-11 11:25:04 +00:00
Michael Achenbach
163b5d705e Revert "[esnext] load iterator.next only once at beginning of iteration"
This reverts commit bf4cc9ee15.

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/857616
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50454}
2018-01-09 16:50:33 +00:00
Caitlin Potter
bf4cc9ee15 [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}
2018-01-09 16:21:30 +00:00
Sathya Gunasekaran
779c080895 [ESNext] Implement optional catch binding
This is just a rebased version of
https://chromium-review.googlesource.com/c/v8/v8/+/571453 with
no functional changes

Bug: v8:6889
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ia082cc09ca527505b288ac88e68e0b74eae94765
Reviewed-on: https://chromium-review.googlesource.com/849423
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50417}
2018-01-08 18:09:34 +00:00
Sathya Gunasekaran
3828ce0cae [class] Ban arguments in class field initializers
Create a new function kind for initializer functions and ban arguments
if used in such a function.

Bug: v8:5367, v8:7183
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Id3089e587b3d6a25f27224045f250e032b831818
Reviewed-on: https://chromium-review.googlesource.com/850547
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50369}
2018-01-04 23:11:25 +00:00