This is the first in a series of changes to reduce the number of
bytecodes generated for the iteration protocol based operations.
The GetIterator bytecode introduced in this change currently loads the
@@iterator symbol from an object that was previously done using the
LdaNamedProperty bytecode. This change uses builtin-based mechanism
that would be extended to perform additional operations in the future
on absorbing the bytecodes associated with the GetIterator operation
from the iteration protocol.
Bug: v8:9489
Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63139}
Cleans up a plethora of JumpIfUndefined().JumpIfNull()
occurances by introducing a new JumpIfUndefinedOrNull
bytecode.
Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63130}
Perform a best-effort check for module context and provide an
appropriate error.
As seen from the import-blah-script.js test, we could have invalid
import expressions in a script context that could result in an error
saying "Cannot use import statement outside a module" which isn't
the ideal error because the error is an incorrect import
expression.
But, when the developer changes to a module context, the
correct error is thrown.
To fix this, we'd have to refactor and call ParseImportDeclaration,
and then throw an appropriate error, which seems like a lot of
overhead for not enough gain.
Bug: v8:9392, v8:6513
Change-Id: I520ebb490fff4d95743a7c751d4095db9a35d41b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1675948
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62358}
As per the new specs, when the exception is thrown by iterator's return method
while doing iterator close because it is not callable, the exception is
suppressed in the same way as if the return method is called and threw an exception.
https://github.com/tc39/ecma262/issues/1398
Bug: v8:9056
Change-Id: I21abd5fdd01d3a957c3c16d9d3aaab9091e43142
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648256
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#62035}
We see crashes in the wild that we suspect are caused by these changes.
This is a manual revert because of conflicts.
Revert "[turbofan] Fix incorrect CheckNonEmptyString lowering."
This reverts commit b3b7011867.
Revert "[turbofan] Fix incorrect lowering of CheckNonEmptyString."
This reverts commit 5758209026.
Revert "[turbofan] Significantly improve ConsString creation performance."
This reverts commit d6a60a0ee1.
Bug: v8:9147
Change-Id: I262c21e5406a9c4c8ad0e0f995582c5802f0fa1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571613
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60919}
This change significantly improves the performance of string
concatenation in optimized code for the case where the resulting string
is represented as a ConsString. On the relevant test cases we go from
serializeNaive: 10762 ms.
serializeClever: 7813 ms.
serializeConcat: 10271 ms.
to
serializeNaive: 10278 ms.
serializeClever: 5533 ms.
serializeConcat: 10310 ms.
which represents a 30% improvement on the "clever" benchmark, which
tests specifically the ConsString creation performance.
This was accomplished via a couple of different steps, which are briefly
outlined here:
1. The empty_string gets its own map, so that we can easily recognize
and handle it appropriately in the TurboFan type system. This
allows us to express (and assert) that the inputs to NewConsString
are non-empty strings, making sure that TurboFan no longer creates
"crippled ConsStrings" with empty left or right hand sides.
2. Further split the existing String types in TurboFan to be able to
distinguish between OneByte and TwoByte strings on the type system
level. This allows us to avoid having to dynamically lookup the
resulting ConsString map in case of ConsString creation (i.e. when
we know that both input strings are OneByte strings or at least
one of the input strings is TwoByte).
3. We also introduced more finegrained feedback for the Add bytecode
in the interpreter, having it collect feedback about ConsStrings,
specifically ConsOneByteString and ConsTwoByteString. This feedback
can be used by TurboFan to only inline the relevant code for what
was seen so far. This allows us to remove the Octane/Splay specific
magic in JSTypedLowering to detect ConsString creation, and instead
purely rely on the feedback of what was seen so far (also making it
possible to change the semantics of NewConsString to be a low-level
operator, which is only introduced in SimplifiedLowering by looking
at the input types of StringConcat).
4. On top of the before mentioned type and interpreter changes we added
new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and
CheckNonEmptyTwoByteString, which perform the appropriate (dynamic)
checks.
There are several more improvements that are possible based on this, but
since the change was already quite big, we decided not to put everything
into the first change, but do some follow up tweaks to the type system,
and builtin optimizations later.
Tbr: mstarzinger@chromium.org
Bug: v8:8834, v8:8931, v8:8939, v8:8951
Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Doc: https://bit.ly/fast-string-concatenation-in-javascript
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60318}
This is a pre-work for allocating feedback vectors lazily. Feedback cells
are required to share the feedback vectors across the different closures
of the same function. Currently, they are held in the CreateClosureSlot
in the feedback vector. With lazy feedback vector allocation, we may not
have a feedback vector. However, we still need a place to store the
feedback cells, so if feedback vector is allocated in future it can still
be shared across closures.
Here is the detailed design doc:
https://docs.google.com/document/d/1m2PTNChrlJqw9MiwK_xEJfqbFHAgEHmgGqmIN49PaBY/edit
BUG=v8:8394
Change-Id: Ib406d862b2809b1293bfecdcfcf8dea3127cb1c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503753
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60147}
This is a reland of 35269f77f8
Switches on an expression that unconditionally throws would have all their
case statements dead, causing a DCHECK error in the SwitchBuilder. This
fixes up the DCHECK to allow dead labels.
Original change's description:
> [ignition] Skip binding dead labels
>
> BytecodeLabels for forward jumps may create a dead basic block if their
> corresponding jump was elided (due to it dead code elimination). We can
> avoid generating such dead basic blocks by skipping the label bind when
> no corresponding jump has been observed. This works because all jumps
> except JumpLoop are forward jumps, so we only have to special case one
> Bind for loop headers to bind unconditionally.
>
> Since Binds are now conditional on a jump existing, we can no longer rely
> on using Bind to get the current offset (e.g. at the beginning of a try
> block). Instead, we now expose the current offset in the bytecode array
> writer. Conveniently, this means that we can be a bit smarter about basic
> blocks around these statements.
>
> As a drive-by, remove the unused Bind(target,label) function.
>
> Bug: chromium:934166
> Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
> Reviewed-on: https://chromium-review.googlesource.com/c/1488763
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59942}
TBR=rmcilroy@chromium.org
Bug: chromium:934166
Change-Id: If6eab4162106717ce64a2dc477000c6a76354cb4
Reviewed-on: https://chromium-review.googlesource.com/c/1494535
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59948}
This reverts commit 35269f77f8.
Reason for revert: Fuzzer unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Fuzzer/29792
Original change's description:
> [ignition] Skip binding dead labels
>
> BytecodeLabels for forward jumps may create a dead basic block if their
> corresponding jump was elided (due to it dead code elimination). We can
> avoid generating such dead basic blocks by skipping the label bind when
> no corresponding jump has been observed. This works because all jumps
> except JumpLoop are forward jumps, so we only have to special case one
> Bind for loop headers to bind unconditionally.
>
> Since Binds are now conditional on a jump existing, we can no longer rely
> on using Bind to get the current offset (e.g. at the beginning of a try
> block). Instead, we now expose the current offset in the bytecode array
> writer. Conveniently, this means that we can be a bit smarter about basic
> blocks around these statements.
>
> As a drive-by, remove the unused Bind(target,label) function.
>
> Bug: chromium:934166
> Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
> Reviewed-on: https://chromium-review.googlesource.com/c/1488763
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59942}
TBR=rmcilroy@chromium.org,leszeks@chromium.org
Change-Id: I8118e54e0afa5e08b0a0a874c952f8a01f1c3242
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:934166
Reviewed-on: https://chromium-review.googlesource.com/c/1494534
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59947}
BytecodeLabels for forward jumps may create a dead basic block if their
corresponding jump was elided (due to it dead code elimination). We can
avoid generating such dead basic blocks by skipping the label bind when
no corresponding jump has been observed. This works because all jumps
except JumpLoop are forward jumps, so we only have to special case one
Bind for loop headers to bind unconditionally.
Since Binds are now conditional on a jump existing, we can no longer rely
on using Bind to get the current offset (e.g. at the beginning of a try
block). Instead, we now expose the current offset in the bytecode array
writer. Conveniently, this means that we can be a bit smarter about basic
blocks around these statements.
As a drive-by, remove the unused Bind(target,label) function.
Bug: chromium:934166
Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
Reviewed-on: https://chromium-review.googlesource.com/c/1488763
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59942}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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.orgTBR=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}
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}
