2017-02-24 17:48:49 +00:00
|
|
|
#
|
|
|
|
|
# Autogenerated by generate-bytecode-expectations.
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
wrap: no
|
|
|
|
|
test function name: f
|
|
|
|
|
async iteration: yes
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
snippet: "
|
|
|
|
|
async function f() {
|
|
|
|
|
for await (let x of [1, 2, 3]) {}
|
|
|
|
|
}
|
|
|
|
|
f();
|
|
|
|
|
"
|
2019-01-14 14:15:52 +00:00
|
|
|
frame size: 21
|
2017-02-24 17:48:49 +00:00
|
|
|
parameter count: 1
|
2019-02-28 13:34:26 +00:00
|
|
|
bytecode array length: 325
|
2017-02-24 17:48:49 +00:00
|
|
|
bytecodes: [
|
2019-01-31 15:36:58 +00:00
|
|
|
B(SwitchOnGeneratorState), R(0), U8(0), U8(2),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Mov), R(closure), R(4),
|
|
|
|
|
B(Mov), R(this), R(5),
|
|
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionEnter), R(4), U8(2),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Star), R(0),
|
2018-10-11 08:35:56 +00:00
|
|
|
/* 16 E> */ B(StackCheck),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Mov), R(context), R(4),
|
|
|
|
|
/* 43 S> */ B(CreateArrayLiteral), U8(2), U8(0), U8(37),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(Star), R(7),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(LdaNamedProperty), R(7), U8(3), U8(1),
|
2017-03-09 14:40:02 +00:00
|
|
|
B(JumpIfUndefined), U8(17),
|
|
|
|
|
B(JumpIfNull), U8(15),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(8),
|
|
|
|
|
B(CallProperty0), R(8), R(7), U8(3),
|
2017-03-09 14:40:02 +00:00
|
|
|
B(JumpIfJSReceiver), U8(23),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(CallRuntime), U16(Runtime::kThrowSymbolAsyncIteratorInvalid), R(0), U8(0),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(LdaNamedProperty), R(7), U8(4), U8(5),
|
|
|
|
|
B(Star), R(8),
|
|
|
|
|
B(CallProperty0), R(8), R(7), U8(7),
|
|
|
|
|
B(Star), R(8),
|
|
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_CreateAsyncFromSyncIterator), R(8), U8(1),
|
|
|
|
|
B(Star), R(6),
|
|
|
|
|
B(LdaNamedProperty), R(6), U8(5), U8(9),
|
2018-01-11 17:24:11 +00:00
|
|
|
B(Star), R(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(LdaFalse),
|
|
|
|
|
B(Star), R(9),
|
|
|
|
|
B(Mov), R(context), R(12),
|
|
|
|
|
B(LdaTrue),
|
|
|
|
|
B(Star), R(9),
|
|
|
|
|
/* 38 S> */ B(CallProperty0), R(5), R(6), U8(11),
|
|
|
|
|
B(Star), R(15),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(0), R(14),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionAwaitUncaught), R(14), U8(2),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(SuspendGenerator), R(0), R(0), U8(14), U8(0),
|
|
|
|
|
B(ResumeGenerator), R(0), R(0), U8(14),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(14),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(15),
|
2017-05-24 15:48:27 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(TestReferenceEqual), R(15),
|
2017-07-13 13:53:13 +00:00
|
|
|
B(JumpIfTrue), U8(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(14),
|
Reland "[async-iteration] implement spec-change to `yield` in async generators"
Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is
unwrapped before the builtin call via Await, allowing Promise rejections to
affect the generator control flow.
Thus, all `yield <expr>` implicitly become `yield await <expr>`.
Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the
generator is resumed with `.return()`, the parameter passed to .return() is
awaited before generator execution properly continues).
BUG=v8:6187, v8:5855
R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org
TBR=rmcilroy@chromium.org, neis@chromium.org
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48
Reviewed-on: https://chromium-review.googlesource.com/594500
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +00:00
|
|
|
B(ReThrow),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(14),
|
|
|
|
|
B(Mov), R(14), R(13),
|
|
|
|
|
B(JumpIfJSReceiver), U8(7),
|
|
|
|
|
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(13), U8(1),
|
|
|
|
|
B(LdaNamedProperty), R(13), U8(6), U8(13),
|
|
|
|
|
B(JumpIfToBooleanTrue), U8(23),
|
|
|
|
|
B(LdaNamedProperty), R(13), U8(7), U8(15),
|
|
|
|
|
B(Star), R(13),
|
|
|
|
|
B(LdaFalse),
|
|
|
|
|
B(Star), R(9),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(13), R(1),
|
2017-02-24 17:48:49 +00:00
|
|
|
/* 23 E> */ B(StackCheck),
|
2019-01-31 15:36:58 +00:00
|
|
|
/* 38 S> */ B(Mov), R(1), R(3),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(13),
|
|
|
|
|
B(JumpLoop), U8(77), I8(0),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaSmi), I8(-1),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(11),
|
|
|
|
|
B(Star), R(10),
|
2017-07-13 13:53:13 +00:00
|
|
|
B(Jump), U8(7),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(11),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(10),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaTheHole),
|
2019-01-14 14:15:52 +00:00
|
|
|
/* 38 E> */ B(SetPendingMessage),
|
|
|
|
|
B(Star), R(12),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(Ldar), R(9),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(JumpIfToBooleanTrue), U8(96),
|
|
|
|
|
B(LdaNamedProperty), R(6), U8(8), U8(17),
|
|
|
|
|
B(Star), R(16),
|
|
|
|
|
B(JumpIfUndefined), U8(88),
|
|
|
|
|
B(JumpIfNull), U8(86),
|
2017-11-07 09:26:56 +00:00
|
|
|
B(TestTypeOf), U8(6),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(JumpIfTrue), U8(18),
|
2019-01-28 18:53:22 +00:00
|
|
|
B(Wide), B(LdaSmi), I16(155),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(Star), R(17),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(LdaConstant), U8(9),
|
|
|
|
|
B(Star), R(18),
|
|
|
|
|
B(CallRuntime), U16(Runtime::kNewTypeError), R(17), U8(2),
|
|
|
|
|
B(Throw),
|
|
|
|
|
B(Mov), R(context), R(17),
|
|
|
|
|
B(CallProperty0), R(16), R(6), U8(19),
|
|
|
|
|
B(Star), R(19),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(0), R(18),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionAwaitUncaught), R(18), U8(2),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(SuspendGenerator), R(0), R(0), U8(18), U8(1),
|
|
|
|
|
B(ResumeGenerator), R(0), R(0), U8(18),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(18),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(19),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(TestReferenceEqual), R(19),
|
2017-07-13 13:53:13 +00:00
|
|
|
B(JumpIfTrue), U8(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(18),
|
2017-07-13 13:53:13 +00:00
|
|
|
B(ReThrow),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(18),
|
|
|
|
|
B(JumpIfJSReceiver), U8(21),
|
|
|
|
|
B(Star), R(20),
|
|
|
|
|
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(20), U8(1),
|
|
|
|
|
B(Jump), U8(12),
|
|
|
|
|
B(Star), R(17),
|
2018-01-23 13:51:38 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(TestReferenceEqual), R(10),
|
2018-01-23 13:51:38 +00:00
|
|
|
B(JumpIfTrue), U8(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(17),
|
2018-01-23 13:51:38 +00:00
|
|
|
B(ReThrow),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(12),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(SetPendingMessage),
|
2017-05-16 15:20:09 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(TestReferenceEqual), R(10),
|
2017-07-13 13:53:13 +00:00
|
|
|
B(JumpIfFalse), U8(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(11),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(ReThrow),
|
|
|
|
|
B(LdaUndefined),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(6),
|
[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 05:54:39 +00:00
|
|
|
B(LdaTrue),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(7),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(0), R(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionResolve), R(5), U8(3),
|
[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 05:54:39 +00:00
|
|
|
/* 57 S> */ B(Return),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(5),
|
|
|
|
|
B(CreateCatchContext), R(5), U8(10),
|
|
|
|
|
B(Star), R(4),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaTheHole),
|
|
|
|
|
B(SetPendingMessage),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(4),
|
|
|
|
|
B(PushContext), R(5),
|
[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 05:54:39 +00:00
|
|
|
B(LdaImmutableCurrentContextSlot), U8(4),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(7),
|
2018-05-30 14:21:39 +00:00
|
|
|
B(LdaTrue),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(8),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(0), R(6),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionReject), R(6), U8(3),
|
2017-02-24 17:48:49 +00:00
|
|
|
/* 57 S> */ B(Return),
|
|
|
|
|
]
|
|
|
|
|
constant pool: [
|
2018-10-11 08:35:56 +00:00
|
|
|
Smi [98],
|
2019-01-14 14:15:52 +00:00
|
|
|
Smi [229],
|
2018-07-05 18:34:09 +00:00
|
|
|
ARRAY_BOILERPLATE_DESCRIPTION_TYPE,
|
2017-02-24 17:48:49 +00:00
|
|
|
SYMBOL_TYPE,
|
|
|
|
|
SYMBOL_TYPE,
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
|
[turbofan] Significantly improve ConsString creation performance.
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}
2019-03-18 19:33:46 +00:00
|
|
|
EMPTY_STRING_TYPE [""],
|
2018-02-16 12:36:47 +00:00
|
|
|
SCOPE_INFO_TYPE,
|
2017-02-24 17:48:49 +00:00
|
|
|
]
|
|
|
|
|
handlers: [
|
2019-02-28 13:34:26 +00:00
|
|
|
[20, 297, 297],
|
2019-01-14 14:15:52 +00:00
|
|
|
[77, 157, 165],
|
|
|
|
|
[211, 260, 262],
|
2017-02-24 17:48:49 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
snippet: "
|
|
|
|
|
async function f() {
|
|
|
|
|
for await (let x of [1, 2, 3]) { return x; }
|
|
|
|
|
}
|
|
|
|
|
f();
|
|
|
|
|
"
|
2019-01-14 14:15:52 +00:00
|
|
|
frame size: 21
|
2017-02-24 17:48:49 +00:00
|
|
|
parameter count: 1
|
2019-02-28 13:34:26 +00:00
|
|
|
bytecode array length: 346
|
2017-02-24 17:48:49 +00:00
|
|
|
bytecodes: [
|
2019-01-31 15:36:58 +00:00
|
|
|
B(SwitchOnGeneratorState), R(0), U8(0), U8(2),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Mov), R(closure), R(4),
|
|
|
|
|
B(Mov), R(this), R(5),
|
|
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionEnter), R(4), U8(2),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Star), R(0),
|
2018-10-11 08:35:56 +00:00
|
|
|
/* 16 E> */ B(StackCheck),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Mov), R(context), R(4),
|
|
|
|
|
/* 43 S> */ B(CreateArrayLiteral), U8(2), U8(0), U8(37),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(Star), R(7),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(LdaNamedProperty), R(7), U8(3), U8(1),
|
2017-03-09 14:40:02 +00:00
|
|
|
B(JumpIfUndefined), U8(17),
|
|
|
|
|
B(JumpIfNull), U8(15),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(8),
|
|
|
|
|
B(CallProperty0), R(8), R(7), U8(3),
|
2017-03-09 14:40:02 +00:00
|
|
|
B(JumpIfJSReceiver), U8(23),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(CallRuntime), U16(Runtime::kThrowSymbolAsyncIteratorInvalid), R(0), U8(0),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(LdaNamedProperty), R(7), U8(4), U8(5),
|
|
|
|
|
B(Star), R(8),
|
|
|
|
|
B(CallProperty0), R(8), R(7), U8(7),
|
|
|
|
|
B(Star), R(8),
|
|
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_CreateAsyncFromSyncIterator), R(8), U8(1),
|
|
|
|
|
B(Star), R(6),
|
|
|
|
|
B(LdaNamedProperty), R(6), U8(5), U8(9),
|
2018-01-11 17:24:11 +00:00
|
|
|
B(Star), R(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(LdaFalse),
|
|
|
|
|
B(Star), R(9),
|
|
|
|
|
B(Mov), R(context), R(12),
|
|
|
|
|
B(LdaTrue),
|
|
|
|
|
B(Star), R(9),
|
|
|
|
|
/* 38 S> */ B(CallProperty0), R(5), R(6), U8(11),
|
|
|
|
|
B(Star), R(15),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(0), R(14),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionAwaitUncaught), R(14), U8(2),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(SuspendGenerator), R(0), R(0), U8(14), U8(0),
|
|
|
|
|
B(ResumeGenerator), R(0), R(0), U8(14),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(14),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(15),
|
2017-05-24 15:48:27 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(TestReferenceEqual), R(15),
|
2017-07-13 13:53:13 +00:00
|
|
|
B(JumpIfTrue), U8(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(14),
|
Reland "[async-iteration] implement spec-change to `yield` in async generators"
Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is
unwrapped before the builtin call via Await, allowing Promise rejections to
affect the generator control flow.
Thus, all `yield <expr>` implicitly become `yield await <expr>`.
Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the
generator is resumed with `.return()`, the parameter passed to .return() is
awaited before generator execution properly continues).
BUG=v8:6187, v8:5855
R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org
TBR=rmcilroy@chromium.org, neis@chromium.org
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48
Reviewed-on: https://chromium-review.googlesource.com/594500
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +00:00
|
|
|
B(ReThrow),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(14),
|
|
|
|
|
B(Mov), R(14), R(13),
|
|
|
|
|
B(JumpIfJSReceiver), U8(7),
|
|
|
|
|
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(13), U8(1),
|
|
|
|
|
B(LdaNamedProperty), R(13), U8(6), U8(13),
|
|
|
|
|
B(JumpIfToBooleanTrue), U8(27),
|
|
|
|
|
B(LdaNamedProperty), R(13), U8(7), U8(15),
|
|
|
|
|
B(Star), R(13),
|
|
|
|
|
B(LdaFalse),
|
|
|
|
|
B(Star), R(9),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(13), R(1),
|
2017-02-24 17:48:49 +00:00
|
|
|
/* 23 E> */ B(StackCheck),
|
2019-01-31 15:36:58 +00:00
|
|
|
/* 38 S> */ B(Mov), R(1), R(3),
|
2019-01-02 16:12:54 +00:00
|
|
|
/* 56 S> */ B(LdaSmi), I8(1),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Mov), R(13), R(11),
|
|
|
|
|
B(Star), R(10),
|
|
|
|
|
B(Jump), U8(15),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaSmi), I8(-1),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(11),
|
|
|
|
|
B(Star), R(10),
|
2019-01-02 16:12:54 +00:00
|
|
|
B(Jump), U8(7),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(11),
|
2019-01-02 16:12:54 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(10),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaTheHole),
|
|
|
|
|
B(SetPendingMessage),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(12),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(Ldar), R(9),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(JumpIfToBooleanTrue), U8(96),
|
|
|
|
|
B(LdaNamedProperty), R(6), U8(8), U8(17),
|
|
|
|
|
B(Star), R(16),
|
|
|
|
|
B(JumpIfUndefined), U8(88),
|
|
|
|
|
B(JumpIfNull), U8(86),
|
2017-11-07 09:26:56 +00:00
|
|
|
B(TestTypeOf), U8(6),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(JumpIfTrue), U8(18),
|
2019-01-28 18:53:22 +00:00
|
|
|
B(Wide), B(LdaSmi), I16(155),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(Star), R(17),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(LdaConstant), U8(9),
|
|
|
|
|
B(Star), R(18),
|
|
|
|
|
B(CallRuntime), U16(Runtime::kNewTypeError), R(17), U8(2),
|
|
|
|
|
B(Throw),
|
|
|
|
|
B(Mov), R(context), R(17),
|
|
|
|
|
B(CallProperty0), R(16), R(6), U8(19),
|
|
|
|
|
B(Star), R(19),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(0), R(18),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionAwaitUncaught), R(18), U8(2),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(SuspendGenerator), R(0), R(0), U8(18), U8(1),
|
|
|
|
|
B(ResumeGenerator), R(0), R(0), U8(18),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(18),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(19),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(TestReferenceEqual), R(19),
|
2017-07-13 13:53:13 +00:00
|
|
|
B(JumpIfTrue), U8(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(18),
|
2017-07-13 13:53:13 +00:00
|
|
|
B(ReThrow),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(18),
|
|
|
|
|
B(JumpIfJSReceiver), U8(21),
|
|
|
|
|
B(Star), R(20),
|
|
|
|
|
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(20), U8(1),
|
|
|
|
|
B(Jump), U8(12),
|
|
|
|
|
B(Star), R(17),
|
2018-01-23 13:51:38 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(TestReferenceEqual), R(10),
|
2018-01-23 13:51:38 +00:00
|
|
|
B(JumpIfTrue), U8(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(17),
|
2018-01-23 13:51:38 +00:00
|
|
|
B(ReThrow),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(Ldar), R(12),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(SetPendingMessage),
|
|
|
|
|
B(Ldar), R(10),
|
|
|
|
|
B(SwitchOnSmiNoFeedback), U8(10), U8(2), I8(0),
|
[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 05:54:39 +00:00
|
|
|
B(Jump), U8(19),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(11),
|
2019-01-02 16:12:54 +00:00
|
|
|
B(ReThrow),
|
[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 05:54:39 +00:00
|
|
|
B(LdaTrue),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(18),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(0), R(16),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Mov), R(11), R(17),
|
|
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionResolve), R(16), U8(3),
|
[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 05:54:39 +00:00
|
|
|
/* 68 S> */ B(Return),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaUndefined),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(6),
|
[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 05:54:39 +00:00
|
|
|
B(LdaTrue),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(7),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(0), R(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionResolve), R(5), U8(3),
|
[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 05:54:39 +00:00
|
|
|
/* 68 S> */ B(Return),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(5),
|
|
|
|
|
B(CreateCatchContext), R(5), U8(12),
|
|
|
|
|
B(Star), R(4),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaTheHole),
|
|
|
|
|
B(SetPendingMessage),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(4),
|
|
|
|
|
B(PushContext), R(5),
|
[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 05:54:39 +00:00
|
|
|
B(LdaImmutableCurrentContextSlot), U8(4),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(7),
|
2018-05-30 14:21:39 +00:00
|
|
|
B(LdaTrue),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(8),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(0), R(6),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionReject), R(6), U8(3),
|
2017-02-24 17:48:49 +00:00
|
|
|
/* 68 S> */ B(Return),
|
|
|
|
|
]
|
|
|
|
|
constant pool: [
|
2018-10-11 08:35:56 +00:00
|
|
|
Smi [98],
|
2019-01-14 14:15:52 +00:00
|
|
|
Smi [233],
|
2018-07-05 18:34:09 +00:00
|
|
|
ARRAY_BOILERPLATE_DESCRIPTION_TYPE,
|
2017-02-24 17:48:49 +00:00
|
|
|
SYMBOL_TYPE,
|
|
|
|
|
SYMBOL_TYPE,
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
|
[turbofan] Significantly improve ConsString creation performance.
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}
2019-03-18 19:33:46 +00:00
|
|
|
EMPTY_STRING_TYPE [""],
|
2017-05-16 11:36:04 +00:00
|
|
|
Smi [6],
|
2019-01-02 16:12:54 +00:00
|
|
|
Smi [9],
|
2018-02-16 12:36:47 +00:00
|
|
|
SCOPE_INFO_TYPE,
|
2017-02-24 17:48:49 +00:00
|
|
|
]
|
|
|
|
|
handlers: [
|
2019-02-28 13:34:26 +00:00
|
|
|
[20, 318, 318],
|
2019-01-14 14:15:52 +00:00
|
|
|
[77, 161, 169],
|
|
|
|
|
[215, 264, 266],
|
2017-02-24 17:48:49 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
snippet: "
|
|
|
|
|
async function f() {
|
|
|
|
|
for await (let x of [10, 20, 30]) {
|
|
|
|
|
if (x == 10) continue;
|
|
|
|
|
if (x == 20) break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
f();
|
|
|
|
|
"
|
2019-01-14 14:15:52 +00:00
|
|
|
frame size: 21
|
2017-02-24 17:48:49 +00:00
|
|
|
parameter count: 1
|
2019-02-28 13:34:26 +00:00
|
|
|
bytecode array length: 341
|
2017-02-24 17:48:49 +00:00
|
|
|
bytecodes: [
|
2019-01-31 15:36:58 +00:00
|
|
|
B(SwitchOnGeneratorState), R(0), U8(0), U8(2),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Mov), R(closure), R(4),
|
|
|
|
|
B(Mov), R(this), R(5),
|
|
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionEnter), R(4), U8(2),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Star), R(0),
|
2018-10-11 08:35:56 +00:00
|
|
|
/* 16 E> */ B(StackCheck),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Mov), R(context), R(4),
|
|
|
|
|
/* 43 S> */ B(CreateArrayLiteral), U8(2), U8(0), U8(37),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(Star), R(7),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(LdaNamedProperty), R(7), U8(3), U8(1),
|
2017-03-09 14:40:02 +00:00
|
|
|
B(JumpIfUndefined), U8(17),
|
|
|
|
|
B(JumpIfNull), U8(15),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(8),
|
|
|
|
|
B(CallProperty0), R(8), R(7), U8(3),
|
2017-03-09 14:40:02 +00:00
|
|
|
B(JumpIfJSReceiver), U8(23),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(CallRuntime), U16(Runtime::kThrowSymbolAsyncIteratorInvalid), R(0), U8(0),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(LdaNamedProperty), R(7), U8(4), U8(5),
|
|
|
|
|
B(Star), R(8),
|
|
|
|
|
B(CallProperty0), R(8), R(7), U8(7),
|
|
|
|
|
B(Star), R(8),
|
|
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_CreateAsyncFromSyncIterator), R(8), U8(1),
|
|
|
|
|
B(Star), R(6),
|
|
|
|
|
B(LdaNamedProperty), R(6), U8(5), U8(9),
|
2018-01-11 17:24:11 +00:00
|
|
|
B(Star), R(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(LdaFalse),
|
|
|
|
|
B(Star), R(9),
|
|
|
|
|
B(Mov), R(context), R(12),
|
|
|
|
|
B(LdaTrue),
|
|
|
|
|
B(Star), R(9),
|
|
|
|
|
/* 38 S> */ B(CallProperty0), R(5), R(6), U8(11),
|
|
|
|
|
B(Star), R(15),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(0), R(14),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionAwaitUncaught), R(14), U8(2),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(SuspendGenerator), R(0), R(0), U8(14), U8(0),
|
|
|
|
|
B(ResumeGenerator), R(0), R(0), U8(14),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(14),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(15),
|
2017-05-24 15:48:27 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(TestReferenceEqual), R(15),
|
2017-07-13 13:53:13 +00:00
|
|
|
B(JumpIfTrue), U8(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(14),
|
Reland "[async-iteration] implement spec-change to `yield` in async generators"
Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is
unwrapped before the builtin call via Await, allowing Promise rejections to
affect the generator control flow.
Thus, all `yield <expr>` implicitly become `yield await <expr>`.
Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the
generator is resumed with `.return()`, the parameter passed to .return() is
awaited before generator execution properly continues).
BUG=v8:6187, v8:5855
R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org
TBR=rmcilroy@chromium.org, neis@chromium.org
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48
Reviewed-on: https://chromium-review.googlesource.com/594500
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#47058}
2017-08-01 14:45:03 +00:00
|
|
|
B(ReThrow),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(14),
|
|
|
|
|
B(Mov), R(14), R(13),
|
|
|
|
|
B(JumpIfJSReceiver), U8(7),
|
|
|
|
|
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(13), U8(1),
|
|
|
|
|
B(LdaNamedProperty), R(13), U8(6), U8(13),
|
|
|
|
|
B(JumpIfToBooleanTrue), U8(39),
|
|
|
|
|
B(LdaNamedProperty), R(13), U8(7), U8(15),
|
|
|
|
|
B(Star), R(13),
|
|
|
|
|
B(LdaFalse),
|
|
|
|
|
B(Star), R(9),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(13), R(1),
|
2017-02-24 17:48:49 +00:00
|
|
|
/* 23 E> */ B(StackCheck),
|
2019-01-31 15:36:58 +00:00
|
|
|
/* 38 S> */ B(Mov), R(1), R(3),
|
2017-05-24 13:54:57 +00:00
|
|
|
/* 63 S> */ B(LdaSmi), I8(10),
|
2019-01-31 15:36:58 +00:00
|
|
|
/* 69 E> */ B(TestEqual), R(3), U8(17),
|
2017-05-24 13:54:57 +00:00
|
|
|
B(JumpIfFalse), U8(4),
|
2019-01-14 14:15:52 +00:00
|
|
|
/* 76 S> */ B(Jump), U8(11),
|
2017-05-24 13:54:57 +00:00
|
|
|
/* 90 S> */ B(LdaSmi), I8(20),
|
2019-01-31 15:36:58 +00:00
|
|
|
/* 96 E> */ B(TestEqual), R(3), U8(18),
|
2017-05-24 13:54:57 +00:00
|
|
|
B(JumpIfFalse), U8(4),
|
2019-01-14 14:15:52 +00:00
|
|
|
/* 103 S> */ B(Jump), U8(5),
|
|
|
|
|
B(JumpLoop), U8(93), I8(0),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaSmi), I8(-1),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(11),
|
|
|
|
|
B(Star), R(10),
|
2017-07-13 13:53:13 +00:00
|
|
|
B(Jump), U8(7),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(11),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(10),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaTheHole),
|
|
|
|
|
B(SetPendingMessage),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(12),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(Ldar), R(9),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(JumpIfToBooleanTrue), U8(96),
|
|
|
|
|
B(LdaNamedProperty), R(6), U8(8), U8(19),
|
|
|
|
|
B(Star), R(16),
|
|
|
|
|
B(JumpIfUndefined), U8(88),
|
|
|
|
|
B(JumpIfNull), U8(86),
|
2017-11-07 09:26:56 +00:00
|
|
|
B(TestTypeOf), U8(6),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(JumpIfTrue), U8(18),
|
2019-01-28 18:53:22 +00:00
|
|
|
B(Wide), B(LdaSmi), I16(155),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(Star), R(17),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(LdaConstant), U8(9),
|
|
|
|
|
B(Star), R(18),
|
|
|
|
|
B(CallRuntime), U16(Runtime::kNewTypeError), R(17), U8(2),
|
|
|
|
|
B(Throw),
|
|
|
|
|
B(Mov), R(context), R(17),
|
|
|
|
|
B(CallProperty0), R(16), R(6), U8(21),
|
|
|
|
|
B(Star), R(19),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(0), R(18),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionAwaitUncaught), R(18), U8(2),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(SuspendGenerator), R(0), R(0), U8(18), U8(1),
|
|
|
|
|
B(ResumeGenerator), R(0), R(0), U8(18),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(18),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_GeneratorGetResumeMode), R(0), U8(1),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(19),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(TestReferenceEqual), R(19),
|
2017-07-13 13:53:13 +00:00
|
|
|
B(JumpIfTrue), U8(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(18),
|
2017-07-13 13:53:13 +00:00
|
|
|
B(ReThrow),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(18),
|
|
|
|
|
B(JumpIfJSReceiver), U8(21),
|
|
|
|
|
B(Star), R(20),
|
|
|
|
|
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(20), U8(1),
|
|
|
|
|
B(Jump), U8(12),
|
|
|
|
|
B(Star), R(17),
|
2018-01-23 13:51:38 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(TestReferenceEqual), R(10),
|
2018-01-23 13:51:38 +00:00
|
|
|
B(JumpIfTrue), U8(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(17),
|
2018-01-23 13:51:38 +00:00
|
|
|
B(ReThrow),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(12),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(SetPendingMessage),
|
2017-05-16 15:20:09 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(TestReferenceEqual), R(10),
|
2017-07-13 13:53:13 +00:00
|
|
|
B(JumpIfFalse), U8(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(11),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(ReThrow),
|
|
|
|
|
B(LdaUndefined),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(6),
|
[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 05:54:39 +00:00
|
|
|
B(LdaTrue),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(7),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(0), R(5),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionResolve), R(5), U8(3),
|
[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 05:54:39 +00:00
|
|
|
/* 114 S> */ B(Return),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(5),
|
|
|
|
|
B(CreateCatchContext), R(5), U8(10),
|
|
|
|
|
B(Star), R(4),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaTheHole),
|
|
|
|
|
B(SetPendingMessage),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(4),
|
|
|
|
|
B(PushContext), R(5),
|
[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 05:54:39 +00:00
|
|
|
B(LdaImmutableCurrentContextSlot), U8(4),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(7),
|
2018-05-30 14:21:39 +00:00
|
|
|
B(LdaTrue),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(8),
|
2019-01-31 15:36:58 +00:00
|
|
|
B(Mov), R(0), R(6),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionReject), R(6), U8(3),
|
2017-02-24 17:48:49 +00:00
|
|
|
/* 114 S> */ B(Return),
|
|
|
|
|
]
|
|
|
|
|
constant pool: [
|
2018-10-11 08:35:56 +00:00
|
|
|
Smi [98],
|
2019-01-14 14:15:52 +00:00
|
|
|
Smi [245],
|
2018-07-05 18:34:09 +00:00
|
|
|
ARRAY_BOILERPLATE_DESCRIPTION_TYPE,
|
2017-02-24 17:48:49 +00:00
|
|
|
SYMBOL_TYPE,
|
|
|
|
|
SYMBOL_TYPE,
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
|
[turbofan] Significantly improve ConsString creation performance.
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}
2019-03-18 19:33:46 +00:00
|
|
|
EMPTY_STRING_TYPE [""],
|
2018-02-16 12:36:47 +00:00
|
|
|
SCOPE_INFO_TYPE,
|
2017-02-24 17:48:49 +00:00
|
|
|
]
|
|
|
|
|
handlers: [
|
2019-02-28 13:34:26 +00:00
|
|
|
[20, 313, 313],
|
2019-01-14 14:15:52 +00:00
|
|
|
[77, 173, 181],
|
|
|
|
|
[227, 276, 278],
|
2017-02-24 17:48:49 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
snippet: "
|
|
|
|
|
async function f() {
|
|
|
|
|
var x = { 'a': 1, 'b': 2 };
|
|
|
|
|
for (x['a'] of [1,2,3]) { return x['a']; }
|
|
|
|
|
}
|
|
|
|
|
f();
|
|
|
|
|
"
|
2018-10-11 08:35:56 +00:00
|
|
|
frame size: 16
|
2017-02-24 17:48:49 +00:00
|
|
|
parameter count: 1
|
2019-02-28 13:34:26 +00:00
|
|
|
bytecode array length: 261
|
2017-02-24 17:48:49 +00:00
|
|
|
bytecodes: [
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Mov), R(closure), R(2),
|
|
|
|
|
B(Mov), R(this), R(3),
|
|
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionEnter), R(2), U8(2),
|
2018-10-04 07:19:45 +00:00
|
|
|
B(Star), R(0),
|
2018-10-11 08:35:56 +00:00
|
|
|
/* 16 E> */ B(StackCheck),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Mov), R(context), R(2),
|
2018-11-08 08:55:43 +00:00
|
|
|
/* 31 S> */ B(CreateObjectLiteral), U8(0), U8(0), U8(41),
|
|
|
|
|
B(Star), R(1),
|
2017-07-27 12:45:00 +00:00
|
|
|
/* 68 S> */ B(CreateArrayLiteral), U8(1), U8(1), U8(37),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(5),
|
|
|
|
|
B(LdaNamedProperty), R(5), U8(2), U8(2),
|
|
|
|
|
B(Star), R(6),
|
|
|
|
|
B(CallProperty0), R(6), R(5), U8(4),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(JumpIfJSReceiver), U8(7),
|
|
|
|
|
B(CallRuntime), U16(Runtime::kThrowSymbolIteratorInvalid), R(0), U8(0),
|
2018-01-11 17:24:11 +00:00
|
|
|
B(Star), R(4),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(LdaNamedProperty), R(4), U8(3), U8(6),
|
|
|
|
|
B(Star), R(3),
|
|
|
|
|
B(LdaFalse),
|
|
|
|
|
B(Star), R(7),
|
|
|
|
|
B(Mov), R(context), R(10),
|
|
|
|
|
B(LdaTrue),
|
|
|
|
|
B(Star), R(7),
|
|
|
|
|
/* 59 S> */ B(CallProperty0), R(3), R(4), U8(8),
|
|
|
|
|
B(Star), R(11),
|
|
|
|
|
B(JumpIfJSReceiver), U8(7),
|
|
|
|
|
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(11), U8(1),
|
|
|
|
|
B(LdaNamedProperty), R(11), U8(4), U8(10),
|
|
|
|
|
B(JumpIfToBooleanTrue), U8(33),
|
|
|
|
|
B(LdaNamedProperty), R(11), U8(5), U8(12),
|
|
|
|
|
B(Star), R(11),
|
|
|
|
|
B(LdaFalse),
|
|
|
|
|
B(Star), R(7),
|
|
|
|
|
B(Ldar), R(11),
|
|
|
|
|
/* 58 E> */ B(StaNamedProperty), R(1), U8(6), U8(14),
|
2017-02-24 17:48:49 +00:00
|
|
|
/* 53 E> */ B(StackCheck),
|
2018-10-11 08:35:56 +00:00
|
|
|
/* 87 S> */ B(LdaNamedProperty), R(1), U8(6), U8(16),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(9),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaSmi), I8(1),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(8),
|
|
|
|
|
B(Mov), R(1), R(12),
|
|
|
|
|
B(Jump), U8(15),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaSmi), I8(-1),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(9),
|
|
|
|
|
B(Star), R(8),
|
2019-01-02 16:12:54 +00:00
|
|
|
B(Jump), U8(7),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(9),
|
2019-01-02 16:12:54 +00:00
|
|
|
B(LdaZero),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(8),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaTheHole),
|
|
|
|
|
B(SetPendingMessage),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(10),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(Ldar), R(7),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(JumpIfToBooleanTrue), U8(60),
|
|
|
|
|
B(LdaNamedProperty), R(4), U8(7), U8(18),
|
|
|
|
|
B(Star), R(13),
|
|
|
|
|
B(JumpIfUndefined), U8(52),
|
|
|
|
|
B(JumpIfNull), U8(50),
|
2017-11-07 09:26:56 +00:00
|
|
|
B(TestTypeOf), U8(6),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(JumpIfTrue), U8(18),
|
2019-01-28 18:53:22 +00:00
|
|
|
B(Wide), B(LdaSmi), I16(155),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(Star), R(14),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(LdaConstant), U8(8),
|
|
|
|
|
B(Star), R(15),
|
|
|
|
|
B(CallRuntime), U16(Runtime::kNewTypeError), R(14), U8(2),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(Throw),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Mov), R(context), R(14),
|
|
|
|
|
B(CallProperty0), R(13), R(4), U8(20),
|
|
|
|
|
B(JumpIfJSReceiver), U8(21),
|
|
|
|
|
B(Star), R(15),
|
|
|
|
|
B(CallRuntime), U16(Runtime::kThrowIteratorResultNotAnObject), R(15), U8(1),
|
|
|
|
|
B(Jump), U8(12),
|
|
|
|
|
B(Star), R(14),
|
|
|
|
|
B(LdaZero),
|
|
|
|
|
B(TestReferenceEqual), R(8),
|
|
|
|
|
B(JumpIfTrue), U8(5),
|
|
|
|
|
B(Ldar), R(14),
|
|
|
|
|
B(ReThrow),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(Ldar), R(10),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(SetPendingMessage),
|
|
|
|
|
B(Ldar), R(8),
|
|
|
|
|
B(SwitchOnSmiNoFeedback), U8(9), U8(2), I8(0),
|
[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 05:54:39 +00:00
|
|
|
B(Jump), U8(19),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(9),
|
2019-01-02 16:12:54 +00:00
|
|
|
B(ReThrow),
|
[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 05:54:39 +00:00
|
|
|
B(LdaFalse),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(Star), R(15),
|
|
|
|
|
B(Mov), R(0), R(13),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Mov), R(9), R(14),
|
2018-10-11 08:35:56 +00:00
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionResolve), R(13), U8(3),
|
[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 05:54:39 +00:00
|
|
|
/* 96 S> */ B(Return),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaUndefined),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(4),
|
2018-01-11 17:24:11 +00:00
|
|
|
B(LdaFalse),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(5),
|
|
|
|
|
B(Mov), R(0), R(3),
|
|
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionResolve), R(3), U8(3),
|
[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 05:54:39 +00:00
|
|
|
/* 96 S> */ B(Return),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(3),
|
|
|
|
|
B(CreateCatchContext), R(3), U8(11),
|
|
|
|
|
B(Star), R(2),
|
2017-02-24 17:48:49 +00:00
|
|
|
B(LdaTheHole),
|
|
|
|
|
B(SetPendingMessage),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Ldar), R(2),
|
|
|
|
|
B(PushContext), R(3),
|
[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 05:54:39 +00:00
|
|
|
B(LdaImmutableCurrentContextSlot), U8(4),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(5),
|
2018-05-30 14:21:39 +00:00
|
|
|
B(LdaFalse),
|
2019-01-14 14:15:52 +00:00
|
|
|
B(Star), R(6),
|
|
|
|
|
B(Mov), R(0), R(4),
|
|
|
|
|
B(InvokeIntrinsic), U8(Runtime::k_AsyncFunctionReject), R(4), U8(3),
|
2017-02-24 17:48:49 +00:00
|
|
|
/* 96 S> */ B(Return),
|
|
|
|
|
]
|
|
|
|
|
constant pool: [
|
2018-07-05 18:34:09 +00:00
|
|
|
OBJECT_BOILERPLATE_DESCRIPTION_TYPE,
|
|
|
|
|
ARRAY_BOILERPLATE_DESCRIPTION_TYPE,
|
2017-02-24 17:48:49 +00:00
|
|
|
SYMBOL_TYPE,
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["next"],
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["done"],
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["value"],
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["a"],
|
|
|
|
|
ONE_BYTE_INTERNALIZED_STRING_TYPE ["return"],
|
[turbofan] Significantly improve ConsString creation performance.
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}
2019-03-18 19:33:46 +00:00
|
|
|
EMPTY_STRING_TYPE [""],
|
2017-05-16 11:36:04 +00:00
|
|
|
Smi [6],
|
2019-01-02 16:12:54 +00:00
|
|
|
Smi [9],
|
2018-02-16 12:36:47 +00:00
|
|
|
SCOPE_INFO_TYPE,
|
2017-02-24 17:48:49 +00:00
|
|
|
]
|
|
|
|
|
handlers: [
|
2019-02-28 13:34:26 +00:00
|
|
|
[16, 233, 233],
|
2019-01-14 14:15:52 +00:00
|
|
|
[59, 112, 120],
|
|
|
|
|
[166, 179, 181],
|
2017-02-24 17:48:49 +00:00
|
|
|
]
|
|
|
|
|
|
