KeyedLoadSloppyArguments -> KeyedLoadIC_SloppyArguments
KeyedStoreSloppyArguments -> KeyedStoreIC_SloppyArguments
LoadIndexedIntercepter -> LoadIndexedInterceptorIC
StoreInArrayLiteralSlowStub -> StoreInArrayLiteralIC_Slow
StoreInterceptor -> StoreInterceptorIC
StoreSlowElementStub -> KeyedStoreIC_Slow
A few Store stubs were parameterized for the sole purpose of
determining the KeyedAccessStoreMode later on. These are now
implemented as a dedicated builtin for each store mode.
Bug: v8:7777
Change-Id: I743474b0e6c5d6ec2513bb9f8f3a93c5c0535927
Reviewed-on: https://chromium-review.googlesource.com/c/1339859
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57592}
- Add the WeakRef class and its deref() function.
- Add WeakFactory.prototype.makeRef
- Implement the "keep during job" behavior for WeakRef constructor and deref().
- Here we keep the targets alive longer than until the end of the job
(microtask), contradicting the spec. However, this is probably the indended
behavior, see https://github.com/tc39/proposal-weakrefs/issues/39 .
BUG=v8:8179
Change-Id: I41990d41ac1799e34f675d8431b9a7aa7ed3d48d
Reviewed-on: https://chromium-review.googlesource.com/c/1306435
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57242}
The "grow_memory" opcode was renamed to "memory.grow", and the spec
repo was updated to use kExprMemoryGrow internally instead of
kExprGrowMemory (https://github.com/WebAssembly/spec/pull/720).
This CL does the same change for v8.
Drive-by: Rename "current_size" to "memory.size", and a minor cleanup
in wasm-graph-builder.js to bring it in line with the version in the
js-api tests in the spec repo.
R=titzer@chromium.org
Change-Id: If525dba898b2c248890a616d3392c22b45f698ef
Reviewed-on: https://chromium-review.googlesource.com/c/1302057
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57089}
Now that embedded builtins are enabled everywhere*, lazy
deserialization can be turned off and removed.
* Except nosnap builds, on aix and in msvc builds.
Bug: v8:6666, v8:6624, v8:7990
Change-Id: Ib5fefe10e7ff35b13a1eb803fbc3736b8851b22b
Reviewed-on: https://chromium-review.googlesource.com/c/1288638
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57064}
In order for Error.prepareStackTrace() to be able to reconstruct the
same stack frame that the internal mechanism can, we need to also
expose the index for the Promise.all() builtin. The newly added
CallSite#getPromiseIndex() does exactly that.
Bug: v8:7522
Change-Id: I904a4c1005f539536a71926ea1da38b31e2a2e8a
Reviewed-on: https://chromium-review.googlesource.com/c/1304293
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57055}
This adds support for Promise.all() to --async-stack-traces (also at
zero cost, since we can derive the relevant information from the resolve
element closure and context). In case of `Promise.all(a)` the stack
trace even tells you which element of `a` is responsible, for example
```js
async function fine() {}
async function thrower() { await fine(); throw new Error(); }
async function test() { await Promise.all([fine(), thrower()]); }
```
will generate the following stack trace
```
Error
at thrower (something.js:1:9)
at async Promise.all (index 1)
at async test (something.js:3:3)
```
so it not only shows the async Promise.all() frames, but even tells the
user exactly that the second element of `[fine(), thrower()]` is the
relevant one.
Bug: v8:7522
Change-Id: I279a845888e06053cf0e3c9338ab71caabaabf45
Reviewed-on: https://chromium-review.googlesource.com/c/1299248
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57023}
This adds support for having reference type values (i.e. anyref) stored
in an exception. It is the natural combination of the reference type
proposal and the exception handling proposal.
Note that this also introduces support for having write barriers in
generated WasmCode, as this is the first time we are storing references
within generated code. Such write barriers will be needed for other uses
of reference types (e.g. mutable global) regardless.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-anyref
BUG=v8:8341
Change-Id: I1211d4a850954622cb873eede0b4024fecc3dd8b
Reviewed-on: https://chromium-review.googlesource.com/c/1296484
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56995}
There are several core changes in this stub:
1) add a version of KeyedStoreGenericGenerator::SetPropertyInLiteral()
which supports indexed properties directly, witthout KeyedStore
2) add a code stub for SetPropertyInLiteral which uses the version
supporting indexed properties
3) Use the code stub in CloneObjectIC, rather than using the smaller
special-cased version which does not handle Names.
Item 1) involves a refactoring which adds a nice way to reuse code in
KeyedStoreGenericAssembler, which allows deleting a bunch of copy/pasted
code. This makes it easy to reuse the index handling in
KeyedStoreGeneric() without adding adding a bunch more duplicated
handling. Because of this, I consider this to be somewhat of a cleanup,
though if the copied code is preferred, I'm happy to revert to that.
Item 2) is needed for Object.fromEntries(), as it's better to not
require falling back to the slow path if a key happens to be an Smi ---
but this is also optional.
Item 3) benefits the codebase by allowing Object.fromEntries() to use
this fast path without calling into the runtime, and without duplicating
code which is also used by CloneObjectIC.
I am skeptical that this should affect performance significantly. I've
run ObjectLiteralSpread tests, and the mean of scores over 100 runs is
somewhat surprising: CloneObjectIC --- the only user of this code,
has an increased average score, while the polyfill cases score slightly
worse --- However, the overall changes are small and likely flukes.
The complete processed test output is below:
```
// Mean of 100 runs of each benchmark
Babel-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
| With patch | Without patch | diff
Mean | 11530.87 | 12142.92 | -5.04%
-----+---------------------------+---------------------------+-------
BabelAndOverwrite-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
| With patch | Without patch | diff
Mean | 10881.41 | 11260.81 | -3.37%
-----+---------------------------+---------------------------+-------
ObjectAssign-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
| With patch | Without patch | diff
Mean | 6188.92 | 6358.55 | -2.67%
-----+---------------------------+---------------------------+-------
ObjectAssignAndOverwrite-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
| With patch | Without patch | diff
Mean | 6112.80 | 6275.54 | -1.61%
-----+---------------------------+---------------------------+-------
ObjectSpread-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
| With patch | Without patch | diff
Mean | 51942.93 | 50713.17 | +3.46%
-----+---------------------------+---------------------------+-------
ObjectSpreadAndOverwrite-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
| With patch | Without patch | diff
Mean | 51375.23 | 50833.29 | +2.09%
-----+---------------------------+---------------------------+-------
```
BUG=v8:8238, v8:8021
R=ishell@chromium.org, jkummerow@chromium.org
Change-Id: I43e102fc461ffd389b5d6810a73f86e5012d7dee
Reviewed-on: https://chromium-review.googlesource.com/c/1277751
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56957}
This builtin was initially used to create the promise for an async
function, but that is now done by the AsyncFunctionEnter intrinsic.
Bug: v8:7253
Change-Id: I90d0bb31c1548bbfdb53833a5c06161db368f4f0
Reviewed-on: https://chromium-review.googlesource.com/c/1296129
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56878}
This CL extends IterableToListWithSymbolLookup with fast paths
for spreading keys/values iterators of JSMap, and values iterator
of JSSet (which is also the iterator of Set.prototype.keys() and
Set.prototype[Symbol.iterator]()). The fast paths are only taken
if the target still has original iteration behavior.
For iterators it is also required that the iterator is not
partially consumed. After spreading, to be spec-compliant, the
iterator is exhausted. Tests are added.
Bug: v8:7980
Change-Id: Ida74e5ecbbc5ba5488d13a40f2c4bda14c781cbf
Reviewed-on: https://chromium-review.googlesource.com/c/1276632
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#56716}
This also includes ports of Array.p.toString and Array.p.toLocaleString.
Many parts of the old JS implementation are preserved, because
TypedArray.p.join still relies on it. These will be removed once
TypedArray.p.join is ported to Torque.
To simplify implementation, special handling of extremely sparse arrays
has been removed.
Performance improvements vary by array size, elements, and sparse-ness.
Some quick numbers and graphs are here:
https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ia4069a068403ce36676c37401d349aefc976b045
Reviewed-on: https://chromium-review.googlesource.com/c/1196693
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56699}
This JSAsyncFunctionObject represents the implicit generator object
inside of async functions, and also holds the outer promise for the
async functions. This in turn allows us to get rid of the .promise
in the Parser / BytecodeGenerator completely, and will make it
possible to build zero-cost async stack traces independent of the
concrete synchronous part of the stack frame (which currently breaks
in Node.js).
In the bytecode all the async function operations now take this new
JSAsyncFunctionObject instead of passing both the .generator_object
and the .promise, which further simplifies and shrinks the bytecode.
It also reduces the size of async function frames, potentially making
the suspend/resume cheaper.
This also changes `await` to use intrinsics instead of calling to
special JSFunctions on the native context, and thus reduces the size of
the native contexts.
Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator
to TurboFan.
Bug: v8:7253, v8:7522
Change-Id: I2305302285156aa1f71328ecac70377abdd92c80
Ref: nodejs/node#11865
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1273049
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56554}
This change introduces new intrinsics used to desugar async functions
in the Parser and the BytecodeGenerator, namely we introduce a new
%_AsyncFunctionEnter intrinsic that constructs the generator object
for the async function (and in the future will also create the outer
promise for the async function). This generator object is internal
and never escapes to user code, plus since async functions don't have
a "prototype" property, we can just a single map here instead of tracking
the prototype/initial_map on every async function. This saves one word
per async function plus one initial_map per async function that was
invoked at least once.
We also introduce two new intrinsics %_AsyncFunctionReject, which
rejects the outer promise with the caught exception, and another
%_AsyncFunctionResolve, which resolves the outer promise with the
right hand side of the `return` statement. These functions also perform
the DevTools part of the job (aka popping from the promise stack and
sending the debug event). This allows us to get rid of the implicit
try-finally from async functions completely; because the finally
block only called to the %AsyncFunctionPromiseRelease builtin, which
was used to inform DevTools.
In essence we now turn an async function like
```js
async function f(x) { return await bar(x); }
```
into something like this (in Parser and BytecodeGenerator respectively):
```
function f(x) {
.generator_object = %_AsyncFunctionEnter(.closure, this);
.promise = %AsyncFunctionCreatePromise();
try {
.tmp = await bar(x);
return %_AsyncFunctionResolve(.promise, .tmp);
} catch (e) {
return %_AsyncFunctionReject(.promise, e);
}
}
```
Overall the bytecode for async functions gets significantly shorter
already (and will get even shorter once we put the outer promise into
the async function generator object). For example the bytecode for a
simple async function
```js
async function f(x) { return await x; }
```
goes from 175 bytes to 110 bytes (a ~38% reduction in size), which
is in particular due to the simplification around the try-finally
removal.
Overall this seems to improve the doxbee-async-es2017-native test by
around 2-3%. On the test case mentioned in v8:8276 we go from
1124ms to 441ms, which corresponds to a 60% reduction in total
execution time!
Tbr: marja@chromium.org
Bug: v8:7253, v8:7522, v8:8276
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4
Reviewed-on: https://chromium-review.googlesource.com/c/1269041
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56502}
This is a reland of ef2a19a211.
Use AllocateJSArray to avoid allocating an empty fixed array.
Original change's description:
> Add fast path for spreading primitive strings.
>
> This improves the performance on primitive strings of
> IterableToListWithSymbolLookup, which implements the
> CreateArrayFromIterable bytecode. The fast path is only
> taken if the string iterator protector is valid (that is,
> String.prototype[Symbol.iterator] and
> String.prototype[Symbol.iterator]().next are untouched).
>
> This brings spreading of primitive strings closer to the
> performance of the string iterator optimizations.
> (see https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8/).
>
> Bug: chromium:881273, v8:7980
> Change-Id: Ic8d8619da2f2afcc9346203613a844f62653fd7a
> Reviewed-on: https://chromium-review.googlesource.com/1243110
> Commit-Queue: Hai Dang <dhai@google.com>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56329}
Bug: chromium:881273, v8:7980
Change-Id: I746c57ddfc300e1032057b5125bc824adf5c2cd3
Reviewed-on: https://chromium-review.googlesource.com/c/1267497
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56438}
This reverts commit ef2a19a211.
Reason for revert: Broken layout tests: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux_chromium_rel_ng/201392
Original change's description:
> Add fast path for spreading primitive strings.
>
> This improves the performance on primitive strings of
> IterableToListWithSymbolLookup, which implements the
> CreateArrayFromIterable bytecode. The fast path is only
> taken if the string iterator protector is valid (that is,
> String.prototype[Symbol.iterator] and
> String.prototype[Symbol.iterator]().next are untouched).
>
> This brings spreading of primitive strings closer to the
> performance of the string iterator optimizations.
> (see https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8/).
>
> Bug: chromium:881273, v8:7980
> Change-Id: Ic8d8619da2f2afcc9346203613a844f62653fd7a
> Reviewed-on: https://chromium-review.googlesource.com/1243110
> Commit-Queue: Hai Dang <dhai@google.com>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56329}
TBR=ulan@chromium.org,neis@chromium.org,sigurds@chromium.org,bmeurer@chromium.org,dhai@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:881273, v8:7980
Change-Id: I4868160b87bdebf9fd2ff346aefd4cdce23681a1
Reviewed-on: https://chromium-review.googlesource.com/c/1261022
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56365}
This introduces a new flag --async-stack-traces, which enables zero-cost
async stack traces. This enriches the non-standard Error.stack property
with async stack frames computed from walking up the promise chains and
collecting all the await suspension points along the way. In Error.stack
these async frames are marked with "async" to make it possible to
distinguish them from regular frames, for example:
```
Error: Some error message
at bar (<anonymous>)
at async foo (<anonymous>)
```
It's zero-cost because no additional information is collected during the
execution of the program, but only the information already present in the
promise chains is used to reconstruct an approximation of the async stack
in case of an exception. But this approximation is limited to suspension
points at await's in async functions. This depends on a recent ECMAScript
specification change, flagged behind --harmony-await-optimization and
implied the --async-stack-traces flag. Without this change there's no
way to get from the outer promise of an async function to the rest of
the promise chain, since the link is broken by the indirection introduced
by await.
For async functions the special outer promise, named .promise in the
Parser desugaring, is now forcible allocated to stack slot 0 during
scope resolution, to make it accessible to the stack frame construction
logic. Note that this first prototype doesn't yet work fully support
async generators and might have other limitations.
Bug: v8:7522
Ref: nodejs/node#11865
Change-Id: I0cc8e3cdfe45dab56d3d506be2d25907409b01a9
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1256762
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56363}
This improves the performance on primitive strings of
IterableToListWithSymbolLookup, which implements the
CreateArrayFromIterable bytecode. The fast path is only
taken if the string iterator protector is valid (that is,
String.prototype[Symbol.iterator] and
String.prototype[Symbol.iterator]().next are untouched).
This brings spreading of primitive strings closer to the
performance of the string iterator optimizations.
(see https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8/).
Bug: chromium:881273, v8:7980
Change-Id: Ic8d8619da2f2afcc9346203613a844f62653fd7a
Reviewed-on: https://chromium-review.googlesource.com/1243110
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56329}
This reduces the size a "Throw" or "Rethrow" takes in generated code by
switching from runtime calls to using WebAssembly runtime stubs. It also
removes a specialized runtime function and instead uses {Runtime_Throw}
which is generic and used by all code (including JavaScript code).
R=clemensh@chromium.org
BUG=v8:8091
Change-Id: Id4f637525f2ea9d81227931b1290d90ca5f376d1
Reviewed-on: https://chromium-review.googlesource.com/1243106
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56215}
This fast path copies the backing store and replaces holes with undefined.
In the case where the array is holey but there is no actual holes, the
resulting array is of the same elements kind as the source array. If a hole
does appear, the resulting array will be of PACKED_ELEMENTS kind so that it
can contain undefined.
The builtin CloneFastJSArrayFillingHoles includes this fast path, but
CloneFastJSArray does not (it still behaves as before). In case of fast
packed arrays, CloneFastJSArrayFillingHoles behaves the same as
CloneFastJSArray.
Bug: chromium:881273, v8:7980
Change-Id: I49c641c1a673313f06aeed93077031ab6b017b6d
Reviewed-on: https://chromium-review.googlesource.com/1236573
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56209}
Previously, Atomics.notify was just an alias to Atomics.wake, which
doesn't quite let us add a use counter for these individual builtins.
This patch refactors the existing Atomics.wake into a separate
function that is called from two separate builtins.
Bug: v8:7883
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: If54c8f769b7949d88d327cfb2f70db394f32a0b7
Reviewed-on: https://chromium-review.googlesource.com/1234581
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56105}
This always creates the bytecode handlers as part of the builtins table
regardless of the V8_EMBEDDED_BYTECODE_HANDLERS definition.
Lazy deserialization of bytecode handlers is enabled for this flow by
moving the three lazy bytecode deserializers from the strong roots into
the builtins table (ensuring that they not marked lazy themselves).
To simplify lazy deserialization, the illegal bytecode handler is made
non-lazy so that GetAndMaybeDeserializeBytecodeHandler doesn't to know
about it.
Since the bytecode handlers are now always part of the builtins table,
many bytecode specific methods are removed, including logging and in
BuiltinsSerializer and BuiltinsDeserializer.
Removes setup-interpreter.h, setup-interpreter-internal.cc and
builtin-snapshot-utils.*.
Change-Id: Ie421aa897a04f7b3bcb964c476eb7ab149388d53
Reviewed-on: https://chromium-review.googlesource.com/1220046
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56063}
This reverts commit 99e13e587e.
Reason for revert: Reverting in favor of a general mechanism for this in Torque.
Original change's description:
> [builtins] Add FastCallFunction builtin that elides some checks
>
> This CL adds a new "Call" stub that can be used by builtins that will
> call the same JS call-back function often (e.g. compare function in
> Array.p.sort). The checks have to be done upfront once, but can then
> be omitted.
>
> R=jgruber@chromium.org
>
> Bug: v8:7861
> Change-Id: Id6e4ca27c3d488a7b1f708cbcb4cbe6cc382513e
> Reviewed-on: https://chromium-review.googlesource.com/1208574
> Commit-Queue: Simon Zünd <szuend@google.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55769}
TBR=cbruni@chromium.org,jgruber@chromium.org,szuend@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7861
Change-Id: I47260993ef2a16bd5348bb0b46da4d34d33ea10b
Reviewed-on: https://chromium-review.googlesource.com/1226871
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55897}
Since the removal of Crankshaft there's no use for StringAdd with
pretenuring anymore, so we can remove the extra code and builtins.
Bug: v8:8015
Change-Id: If178c6f1d08841428f42b1baece231268cdae2ad
Reviewed-on: https://chromium-review.googlesource.com/1213206
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55843}
The CSA implementation is a separate handler so that TF has the
opportunity to reduce to a direct call, skipping some of the dispatching
in the CloneObjectIC stub.
This patch moves the looping over a source object's keys and values into the
base CodeStubAssembler, so that it can be shared between ObjectAssignFast
and CloneObjectIC_Slow.
During each step of the loop, storing is delegated to a new SetPropertyInLiteral
helper in KeyedStoreGenericGenerator, which performs a store without consulting
the prototype chain, and automatically reconfigures accessors into data
properties regardless of their attributes.
BUG=v8:8067, v8:7611
R=ishell@chromium.org, jkummerow@chromium.org
Change-Id: I06ae89f37e9b4265aab67389cf68a96529f90578
Reviewed-on: https://chromium-review.googlesource.com/1182122
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55806}
We had an optimization in Crankshaft where we would call into the
megamorphic handler stub directly if an inline cache was already
found to be megamorphic when it hit the optimizing compiler. This
way we could avoid the dispatch overhead when we know that there's
no point in checking for the other states anyways. However we somehow
missed to port this optimization to TurboFan.
Now this change introduces support to call into LoadIC_Megamorphic and
KeyedLoadIC_Megamorphic directly (plus the trampoline versions), which
saves quite a lot of overhead for the cases where the map/name pair is
found in the megamorphic stub cache, and it's quite a simple change. We
can later extend this to also handle the StoreIC and KeyedStoreIC cases
if that turns out to be beneficial.
This improves the score on the Octane/TypeScript test by around ~2%
and the TypeScript test in the web-tooling-benchmark by around ~4%. On
the ARES-6 Air test the steady state mean improves by 2-4%, and on the
ARES-6 ML test the steady state mean seems to also improve by 1-2%, but
that might be within noise.
On a micro-benchmark that just runs `o.x` in a hot loop on a set of 9
different objects, which all have `x` as the first property and are
all in fast mode, we improve by around ~30%, and are now almost on par
with JavaScriptCore.
Bug: v8:6344, v8:6936
Change-Id: Iaa4c6e34c37e78da217ee75f32f6acc95a834250
Reviewed-on: https://chromium-review.googlesource.com/1215623
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55803}
This CL adds a new "Call" stub that can be used by builtins that will
call the same JS call-back function often (e.g. compare function in
Array.p.sort). The checks have to be done upfront once, but can then
be omitted.
R=jgruber@chromium.org
Bug: v8:7861
Change-Id: Id6e4ca27c3d488a7b1f708cbcb4cbe6cc382513e
Reviewed-on: https://chromium-review.googlesource.com/1208574
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55769}
The motivation behind this change is that the WasmArgumentsAdaptor
builtin needed too many registers on ia32 and was blocking work on
adding a root register.
Bug: v8:6666
Change-Id: I9d39af96e8520acc092f5ef4b7f0a159fe4e3b12
Reviewed-on: https://chromium-review.googlesource.com/1209788
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55761}
Previously the builtins table had a value for every single
OperandScale/Bytecode combination regardless of whether it was valid.
This change makes it so that only valid bytecode handlers are stored in
the builtins table. This prevents placeholders being serialized into the
snapshot (and embedded into the binary) saving 9KB in
CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66
entries in the builtins table.
To do this, it generates a new header file bytecodes-builtins-list.h
which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros.
Since list macros cannot be used to conditionally generate elements in
the C-preprocessor, this is done by generator executable, compiled from
interpreter/generate-flat-headers.cc.
Additionally the generator creates the flat bytecode list so that it is
transposed from the previous result, i.e. the results are grouped by
bytecode and then operand scale rather than operand scale then bytecode.
This should give better locality for commonly used bytecodes and may
allow less commonly used ExtraWide bytecodes to never be mapped into
memory at all.
The cost to storing the handlers densely is that looking up a handler
now requires a binary search through the builtins table, but this should
only happen during debugging. It is also fixable at least for non-wide
handlers and could be improved for wide ones if the need arises.
Bug: v8:8068
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667
Reviewed-on: https://chromium-review.googlesource.com/1209304
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55757}
