Replace the explicit ok tracing by setting the scanner to fail, allowing us to
return automatically. RETURN_IF_PARSE_ERROR is now used instead of CHECK_OK to
verify if the parser failed.
In a follow-up CL we'll merge RETURN_IF_PARSE_ERROR after Expect* into an
EXPECT* macro. We'll keep (for now) RETURN_IF_PARSE_ERROR that guard uses of
possible NullExpression (e.g., impl()->IsIdentifier(...)). All other RETURN_IF*
will be removed. Uses after failure can likely later be fixed too by introducing
a FailureExpression.
Bug: v8:8363 ,v8:7926
Change-Id: I9896449eb9be476c453da4417a0bfd17c169ff38
Reviewed-on: https://chromium-review.googlesource.com/c/1294649
Commit-Queue: Florian Sattler <sattlerf@google.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56972}
This allows us to use one underlying buffer rather than 3, and allows memory to
be freed as we're growing the vector.
Change-Id: I45c178a31e8f6d3ee44d3319ce8bca2db2460d33
Reviewed-on: https://chromium-review.googlesource.com/c/1297328
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56966}
This additionally optimizes ExpressionListToExpression in the parser to
allocate Nary if possible. This allows us to drop unnecessary intermediate
objects in the parser, and avoids all the work altogether in the preparser.
Change-Id: I4a7d0ec3a28624c94ed85959d291e54eb81ffce3
Reviewed-on: https://chromium-review.googlesource.com/c/1297952
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56943}
This CL introduces a ScopedPtrList that's a view over an underlying ZonePtrList
buffer. Whenever a ScopedPtrList is the top-of-stack list, you can add values
through it, which will add them to the end of the buffer. Once the list is
done, you can copy out the values to a real ZonePtrList. That way you do not
need to guess what the required size of the list is, and you get better cache
locality.
Change-Id: I2d229d73bb25bbb450ae5b6767ab100abad2b3a3
Reviewed-on: https://chromium-review.googlesource.com/c/1296458
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56939}
This patch merges ClassLiteralProperty::PUBLIC_FIELD and
ClassLiteralProperty::PRIVATE_FIELD into ClassLiteralProperty::FIELD,
and moves the visibility part into ClassLiteralProperty::is_private()
for the ease of adding new combinations in the future.
Bug: v8:8330
R=gsathya@chromium.org
Change-Id: I54f64d05bccb1867d9111e4c80158a6075406d80
Reviewed-on: https://chromium-review.googlesource.com/c/1291052
Reviewed-by: Toon Verwaest <verwaest@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@{#56910}
This also changes Consume to bypass the stackoverflow check. Otherwise the
following pattern wouldn't work:
if (peek() == expected) {
f()
}
f() {
Consume(expected);
}
since the call to f can cause the overflow.
Change-Id: If2fd3181ecdf1fd681f584b630e83e0af4e4bf9d
Reviewed-on: https://chromium-review.googlesource.com/c/1286684
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56782}
Store the bits of a small type into the lower bits
of a pointer type that are free due to alignment.
Furthermore, reordering of members to reduce size of some classes.
Change-Id: I3c619cb74053f64995ea7d0cb395e8edda604f18
Reviewed-on: https://chromium-review.googlesource.com/c/1273019
Commit-Queue: Florian Sattler <sattlerf@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56726}
Adds support for enqueuing parallel parse / compile tasks for eagerly
compiled IIFEs during parsing. If the --parallel-compile-tasks flag is
enabled, the parser will pre-parse eager top-level IIFEs and enqueue a
task on the compiler dispatcher to do the actual parsing / compilation
on a worker thread.
Currently we always enqueue the task, but we likely want to only
enqueue parallel tasks where the script has multiple IIFEs or a
substantial amount of top-level script code before the IIFE to avoid
the main thread having to immediately block on the parallel task. This
work will be done as a follow-up.
BUG=v8:8041
Change-Id: If68d7c374548cabd4ec32f1fb6752da7d6aaae6b
Reviewed-on: https://chromium-review.googlesource.com/c/1275354
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56593}
The primary purpose of this is to untangle a circular dependency
objects.h -> handles.h -> objects.h. Most compilation units only
need message-template.h, without the rest of messages.h.
Bonus: change the enum to an enum class for improved type safety.
Bug: v8:3770
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I8102c55197a450811de2588a68a08e7f99ea6b9e
Reviewed-on: https://chromium-review.googlesource.com/c/1272193
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56583}
Now that the preparser doesn't track errors anymore, it also doesn't make sense
to prepare the message.
Change-Id: Ifc69e67f9220be69812257b0fc18b55097236dbd
Reviewed-on: https://chromium-review.googlesource.com/c/1275818
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56574}
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 is behind a new flag --harmony-namespace-exports.
Bug: v8:8101
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I9c252b6de2b08223fcf3296340b78d721471bdb4
Reviewed-on: https://chromium-review.googlesource.com/c/1258004
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56550}
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}
Instead directly declare the parameters as they are "added to the list".
Change-Id: I3245b5834157eb9f443ceb5da47db231a237d673
Reviewed-on: https://chromium-review.googlesource.com/c/1270815
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56481}
This flag has been on by default for some time. Once
https://chromium-review.googlesource.com/c/v8/v8/+/1270578 lands we need it to
be able to find duplicate parameters (to be spec-compliant).
Change-Id: I222023d7cd955127d3ecca42283b37063e962c58
Reviewed-on: https://chromium-review.googlesource.com/c/1270581
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56468}
Now duplicate parameter detection depends on tracking of unresolved references.
This also fixes finding duplicate parameters of arrow functions nested in other
arrow functions.
Change-Id: I644bfdc513244637345c1069e5c7e5fde713da63
Reviewed-on: https://chromium-review.googlesource.com/c/1270578
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56467}
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}
It was shipped in Chrome 67.
Bug: v8:6791, v8:8238
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I94d8f0aa18570452403a35dea270b18f155c970a
Reviewed-on: https://chromium-review.googlesource.com/1253604
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56310}
PreParser now does not longer track which kind of error occurred.
If we see an error we reparse with the parser and report the error.
Furthermore, this fixes tests in test-parsing.
Change-Id: I1860949fab4d65ff4a5a1b63796c7574494f9d50
Reviewed-on: https://chromium-review.googlesource.com/1231173
Commit-Queue: Florian Sattler <sattlerf@google.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56281}
The Parser inserts a temporary .promise variable to hold the outer
promise for async functions, but doesn't assign an actually visible
name to it. This change puts the name ".promise" on it (similar to
what we do for other special variables like .result), which makes it
easier to debug this (for V8 developers). It's not observable to
regular developers.
Bug: v8:7522, v8:8015
Change-Id: I388352ad931a49102cb5afe350314337a505a150
Reviewed-on: https://chromium-review.googlesource.com/1249106
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56276}
Before I gave the preparser its own zone this was the case. I somewhat
accidentally dropped it when I used set_zone instead; causing large regressions
for certain types of pages.
Bug: chromium:889086
Change-Id: Ib3cf1f926b5c65506c66a97981c4544dccb372aa
Reviewed-on: https://chromium-review.googlesource.com/1245767
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56243}
The previous clear mechanism would also unnecessarily allocate a preparser.
This fixes regressions introduced by
https://chromium-review.googlesource.com/c/v8/v8/+/1238614
Change-Id: Ia3eef371c80857f2cd6cdd5852c849fa7f8716fc
Reviewed-on: https://chromium-review.googlesource.com/1238918
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56171}
Simplify zone discarding for preparsed functions by simply giving the preparser
its own zone that we reset whenever we finish preparsing something.
Change-Id: I3135fbbcd6caefa4654b1ae2b2207377e51bee26
Reviewed-on: https://chromium-review.googlesource.com/1238614
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56146}
Rather than allocating one in the zone and swapping them on discardable zone
swap, we simply swap the zone in the inferrer and allow the stacks to grow in
the outer zone. The inner segments will be dropped anyway.
This also introduces a PreParserFuncNameInferrer that just has dummy
implementations. That way we can avoid checking whether fni_ is nullptr at
runtime.
Change-Id: I0ff41b16d31571fc4606fd46b705d80b423343eb
Reviewed-on: https://chromium-review.googlesource.com/1238573
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56132}
Makes for a nicer stack trace
Bug: v8:5367
Change-Id: I6d77907e08c2c4efc7a1b25016c7e83841c7c574
Reviewed-on: https://chromium-review.googlesource.com/1211444
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55736}
Adds support for zone allocated (off-heap) ConsumedPreParsingScopeData to
enable worker-thread access to PreParsingScopeData during parallel IIFE
compile tasks.
In order to avoid code-duplication, a templated
BaseConsumedPreParsingScopeData is added which implements the logic for
decoding the bytestream into scope data. Two implementations of this
base class are instantiated for each of the underlying serialized scope date:
- ZoneConsumedPreParsedScopeData for exposing ZonePreParsedScopeData
- OnHeapConsumedPreParsedScopeData for exposing on-heap PreParsedScopeData
The interface for each of these classes is the ConsumedPreParsingScopeData,
which exposes the methods required by the parser to deserialize the required
data.
As a side-cleanup, moved Ucs2CharLength and Utf8LengthHelper implementations
to cc file so that we don't get a linker error if one of them are unused by
the cc file including the header.
BUG=v8:8041
Change-Id: Id502312d32fe4a9ddb6f5d2d9d3e3a9d30b9b27d
Reviewed-on: https://chromium-review.googlesource.com/1199462
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55711}
With FLAG_preparser_scope_analysis enabled we now always track
unresolved variables in the preparser. Fix the logic for deciding on
the correct RCS tracing category to be based on what the preparser does.
Change-Id: If691d51e6a2c09e554e4d96c10c37060cc7cca96
Reviewed-on: https://chromium-review.googlesource.com/1193303
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55460}
This is a reland of 1e5b6d99f4
Original change's description:
> [RCS] Create thread local runtime call stats tables for worker threads
>
> Creating a runtime call stats table for each worker thread task is expensive.
> Instead we create a single table per thread, and use TLS to get the correct one
> when starting a worker thread task.
>
> In order to correctly initialize the parser, scanner and parse-info's runtime
> call stats fields, we move creation of the scanner and parser onto the
> background tasks for BackgroundCompileTask and UnoptimizedCompilationJob.
>
> Change-Id: I36064c7fb43290968620b1985cc02637b16f4232
> Reviewed-on: https://chromium-review.googlesource.com/1187522
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55448}
TBR=verwaest@chromium.org
Change-Id: I7c2f48280651d7632d99ee22d86260c72bc16185
Reviewed-on: https://chromium-review.googlesource.com/1193463
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55456}
This reverts commit 1e5b6d99f4.
Reason for revert: Breaks an arm64 MSAN bot - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/22601
Original change's description:
> [RCS] Create thread local runtime call stats tables for worker threads
>
> Creating a runtime call stats table for each worker thread task is expensive.
> Instead we create a single table per thread, and use TLS to get the correct one
> when starting a worker thread task.
>
> In order to correctly initialize the parser, scanner and parse-info's runtime
> call stats fields, we move creation of the scanner and parser onto the
> background tasks for BackgroundCompileTask and UnoptimizedCompilationJob.
>
> Change-Id: I36064c7fb43290968620b1985cc02637b16f4232
> Reviewed-on: https://chromium-review.googlesource.com/1187522
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55448}
TBR=rmcilroy@chromium.org,verwaest@chromium.org
Change-Id: If3f28e65667816b7ae05c5efcb2f463379bc582b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/1193224
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55449}
Creating a runtime call stats table for each worker thread task is expensive.
Instead we create a single table per thread, and use TLS to get the correct one
when starting a worker thread task.
In order to correctly initialize the parser, scanner and parse-info's runtime
call stats fields, we move creation of the scanner and parser onto the
background tasks for BackgroundCompileTask and UnoptimizedCompilationJob.
Change-Id: I36064c7fb43290968620b1985cc02637b16f4232
Reviewed-on: https://chromium-review.googlesource.com/1187522
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55448}
