The valid store types of a {Float64Array} heap view are specified to be
"float?" and "double?". We correctly accepted both types but forgot to
emit the appropriate conversion in the "float?" case. This just adds the
missing conversion expression.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-898974
BUG=chromium:898974,v8:8347
Change-Id: I306b10e2088185b1522da29b1a113908ef9925f2
Reviewed-on: https://chromium-review.googlesource.com/c/1301499
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57025}
GCs should only trigger only trigger when growing external memory but
not when removing it.
- The limit is already lowered when removing memory, so possible future
allocations check against a lowered limit.
- Memory pressure signals are already handled via an explicit V8 API.
Bug: chromium:899035
Change-Id: I96da5862400e06edb8c9fa47357070b3b48560a1
Reviewed-on: https://chromium-review.googlesource.com/c/1301473
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57024}
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}
Currently, because the source float_64_array has an iterator, it hits
the code in the "check_iterator" section of TypedArrayFrom which calls
IterableToList. This builds a temporary PACKED_ELEMENTS array (and boxes
all of the numeric values as HeapNumbers), then uses this as the source
array.
This patch checks if the source array is a TypedArray, and if the iterator
is the built-in one (where we know the iterator's behaviour). If both are
true then it bypasses the creation of this temporary array and uses the
original TypedArray as the source.
This allows it to take advantage of the existing fast code for copying one
typed array to another.
R=hablich@chromium.org, petermarshall@chromium.org
Bug: chromium:884671
Change-Id: I19a944c9d6d5d07699c7dc3ad7196fc871200b62
Reviewed-on: https://chromium-review.googlesource.com/c/1297312
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57022}
We can use GcSafeFindCodeForInnerPointer() when handling a code
added event. This method understands embedded builtins.
Change-Id: I94757f96b7b4ad10cbf7cb5f715d3368cc86b798
Reviewed-on: https://chromium-review.googlesource.com/c/1297953
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57021}
This test was incidentally fixed by
https://chromium-review.googlesource.com/c/v8/v8/+/1280436.
Calls to StartTickSample() and FinishTickSample() are not permitted by
multiple producers. If the signal handler interrupts the main thread,
both might receive the same pointer into the circular buffer and one
will overwrite the data of the other.
This means we cannot call it in tests, and have to use AddSample()
instead.
Bug: v8:8209
Change-Id: I6904204e88077f704f819b52cde0fdaab0f13462
Reviewed-on: https://chromium-review.googlesource.com/c/1299022
Reviewed-by: Alexei Filippov <alph@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57019}
This CL restores consistency with other platforms. ebx is now the
kRootRegister on ia32, and thus not an allocatable register any more.
The PreserveRootIA32 register configuration can be removed since it is
now identical to the Default configuration.
Bug: v8:6666
Change-Id: If4e2b4c52aa8b5db40bcd3b4469004b29c0e3d99
Reviewed-on: https://chromium-review.googlesource.com/c/1299078
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57018}
This skips big-object-literal on bots with dchecks (setting DEBUG) and with
stress mode in general.
NOTRY=true
Bug: v8:8328
Change-Id: I53480d1ee942d2c83e46c8804bd8920a5e36cad2
Reviewed-on: https://chromium-review.googlesource.com/c/1301495
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57017}
When creating a Code object, if it has valid builtin_index then create
its RelocInfo in RO_SPACE. For embedded builds this moves about 48 bytes
into RO_SPACE, but it's considerably more for nosnap builds.
Bug: v8:7464
Change-Id: I598cb960c0068ef4be8d72ae8f5c8d74c0195aca
Reviewed-on: https://chromium-review.googlesource.com/c/1299073
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57016}
Move fixing up Filler objects after deserialization from the
StartupDeserializer to the ReadOnlyDeserializer since that's what
deserializes the Filler maps.
Since only RO_SPACE can contain such objects, skip iterating over all
the spaces and just fix them up directly in RO_SPACE. To this end, the
PagedSpace code is moved to ReadOnlySpace and the Heap fix up method is
removed.
Change-Id: I7a01f1ef298e6d5e74d3173620fb7764c3b598f2
Reviewed-on: https://chromium-review.googlesource.com/c/1299013
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57015}
Checking impl()->IsAsync(identifier) is insufficient since it could be
parenthesized. By checking the token in addition to IsIdentifier guarantees
that we've only seen the single token ASYNC.
Bug: chromium:898812
Change-Id: Id94dd607381050b4bd8cd6d8672a5d11256db7da
Reviewed-on: https://chromium-review.googlesource.com/c/1300134
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57013}
This CL applies the equivalent of the Object -> ObjectPtr
transformation to MaybeObject and HeapObjectReference. We
need no renaming in this case because we can just migrate
them both in one go.
Bug: v8:3770
Change-Id: Ie1259c3e8c556eff00f8bcf534d7270ca9fe00e1
Reviewed-on: https://chromium-review.googlesource.com/c/1298386
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57010}
Port e893eb1403
Original Commit Message:
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=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:8341
LOG=N
Change-Id: I6837a31791654ebe4171f6ecb563939beb3a66dd
Reviewed-on: https://chromium-review.googlesource.com/c/1299899
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#57009}
In a DCHECK inside SetPayload(), MSVC gives a C4806 warning. Use the
right types to avoid this.
Also add pointer-with-payload.h to BUILD.gn.
Change-Id: I10a415250e7d2f06dab7a10bff48eef5890bb723
Reviewed-on: https://chromium-review.googlesource.com/c/1297991
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57003}
A node short-cutting optimization was not updating uses correctly. This
fix makes sure that there are no other users of the node, thus making the
use update unnecessary.
This fix might have negative performance implications.
Change-Id: Ie9bd23caf4434eb2137e111dc5e7c143fd97521c
Reviewed-on: https://chromium-review.googlesource.com/c/1299019
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57001}
This also disables the test on tsan bots and on bots that have
dchecks always enabled, which includes try bots.
Bug: v8:8332, v8:8831
Change-Id: Ib52cd32985d50e89ddfdc525f08f60ddfd981f1e
Reviewed-on: https://chromium-review.googlesource.com/c/1297319
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57000}
The "max_len" argument for fuzzer targets is deprecated. We need to
enforce the limit internally.
R=ahaas@chromium.org
Bug: chromium:894939
Change-Id: I2206bc63d5e39f1aa189e11042a6a0bbcca31b0d
Reviewed-on: https://chromium-review.googlesource.com/c/1299020
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56998}
- Moves call to DeserializeNativeModule into SaveContext to avoid
a crash in IsWasmCodegenAllowed.
Bug: chromium:719172
Change-Id: Idd367824a325fc684f29e335b0c07e515f9fdad3
Reviewed-on: https://chromium-review.googlesource.com/c/1298375
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56997}
This uses the PIMPL idiom to hide the implementation of
{CompilationState} while still allowing to call methods on
{CompilationState} using the externally visible type.
It also allows to pass the {CompilationState} in a unique_ptr
without a custom deleter.
R=ahaas@chromium.org, mstarzinger@chromium.org
Bug: v8:8238
Change-Id: I5e842723270bc6bb36b605253e3e88103caec61a
Reviewed-on: https://chromium-review.googlesource.com/c/1297956
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56996}
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}
This reuses the fast path from IterableToList for Array.from. The fast
paths are taken when .from is called with the receiver Array and the only
argument is the iterable (no mapping function or thisArg).
Bug: v8:7980
Change-Id: I975b0c5e3f838262d7b71ad4dec5111fb031d746
Reviewed-on: https://chromium-review.googlesource.com/c/1297322
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56993}
The {CompilationState} currently stores the {WasmEngine}, while the
{NativeModule} only stores the {WasmCodeManager}. From a high-level
view, this does not make much sense. The {NativeModule} belongs to
exactly one {WasmEngine}, so that link should be stored there. We can
then get to the {WasmCodeManager} from the {WasmEngine}.
This change requires a refactoring of the {WasmCodeManagerTest} which
created {WasmCodeManager}s independent of the {Isolate} and the
{WasmEngine}. This is not supported any more.
Note that in production, each {WasmEngine} owns exactly one
{WasmCodeManager} and one {WasmMemoryTracker}, so testing that a
{WasmMemoryTracker} can be shared by several {WasmCodeManager}s didn't
make sense in the first place.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I582e698be35f97dbd38bf6e12eb7f8ee4fc1f0f2
Reviewed-on: https://chromium-review.googlesource.com/c/1297960
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56992}
This gives us better test coverage.
Also enable --strict-heap-broker by default. I think this
flag is no longer necessary and can be removed soon.
Bug: v8:7790
Change-Id: I55d43dea45ff99bb753189b0d019f945b61752ac
Reviewed-on: https://chromium-review.googlesource.com/c/1298898
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56991}
This removes the last V8_EMBEDDED_BUILTIN ifdefs from the ia32 macro
assembler. It also enables root-relative accesses in a few more spots
where they are cheap.
Bug: v8:6666
Change-Id: I10c8e69d8a76fccd3d0753dad020cced4d92a4a2
Reviewed-on: https://chromium-review.googlesource.com/c/1299018
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56990}
This CL allows ExtractFixedArray to know if the JSArray has only Smi
elements. In that case ExtractFixedArray will always skip write barriers
when copying the Smi-only backing store. In the case that the copying
is not possibly conflicting with the concurrent marker, CopyElements will
efficiently use memcpy for further performance.
This improves the performance of ExtractFastJSArray and CloneFastJSArray.
As a result, performance of copying Smi arrays by slice() and spreading is
improved, except for spreading Smi holey arrays.
Bug: v8:7980
Change-Id: Ie39f8abf3b5039cc12a8ca7ece81352375e0e9da
Reviewed-on: https://chromium-review.googlesource.com/c/1286340
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#56989}
Since tokens turn illegal automatically upon failure, we can delay checking in
places where we'll return upon illegal token anyway. We still need checks
before uses of a possible invalid expression (nullptr in parser), so keep those
checks for now; possibly pushing a previously higher check to right before the
dereference.
Bug: v8:8363 ,v8:7926
Change-Id: Ia402fc83c15f4c3258a335614b9213f8211a3c53
Reviewed-on: https://chromium-review.googlesource.com/c/1299081
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56985}
This is a reland of a31a623047
Original change's description:
> [ia32] Remove poisoning logic on ia32
>
> Poisoning has been disabled by default on ia32 a while ago. This CL
> removes its logic from ia32 code generation, which will let us move
> towards fuller (and unconditional) root register support.
>
> Bug: chromium:860429, v8:8254
> Change-Id: I8f672cf48a6ffc7bf21e7794c1b7463d7f8b9594
> Reviewed-on: https://chromium-review.googlesource.com/c/1296131
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56978}
Tbr: mstarzinger@chromium.org,jarin@chromium.org
Bug: chromium:860429, v8:8254
Change-Id: Ia65ac57fdc6b9a0f59cc64455d6a000005e9be3b
Reviewed-on: https://chromium-review.googlesource.com/c/1299080
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56984}
This CL extracts some functionality out of the {PrepareAndStartCompile}
step, in order to reuse that from the {AsyncStreamingProcessor}. We
currently schedule a {PrepareAndStartCompile} task to get the same
effect, and rely on the internal implementation to do the right thing.
R=ahaas@chromium.org
Bug: v8:8238
Change-Id: I43135fe488a5f72c09307ac955381c69b7987ec1
Reviewed-on: https://chromium-review.googlesource.com/c/1297321
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56983}
PrepareElementsForSort must return a number less than or equal the array
length.
Bug: chromium:897512, v8:7382
Change-Id: If5f9c4d052e623ab9f3300b8534603abbee859fa
Reviewed-on: https://chromium-review.googlesource.com/c/1297958
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56982}
This reverts commit a31a623047.
Reason for revert:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21332
Original change's description:
> [ia32] Remove poisoning logic on ia32
>
> Poisoning has been disabled by default on ia32 a while ago. This CL
> removes its logic from ia32 code generation, which will let us move
> towards fuller (and unconditional) root register support.
>
> Bug: chromium:860429, v8:8254
> Change-Id: I8f672cf48a6ffc7bf21e7794c1b7463d7f8b9594
> Reviewed-on: https://chromium-review.googlesource.com/c/1296131
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56978}
TBR=mstarzinger@chromium.org,jarin@chromium.org,jgruber@chromium.org
Change-Id: I305e9e1719fb4b3f8ef267c232723db9b52966e9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:860429, v8:8254
Reviewed-on: https://chromium-review.googlesource.com/c/1299015
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56980}
Resets the isolate's context to nullptr in debug builds during bytecode finalization
to ensure that we don't rely on the native context during context independent
unoptimized compilation.
BUG=chromium:898076, v8:8041
Change-Id: Ifaa5006a7a3d31d7fbd535ebb63f8889c75526c4
Reviewed-on: https://chromium-review.googlesource.com/c/1297961
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56979}
Poisoning has been disabled by default on ia32 a while ago. This CL
removes its logic from ia32 code generation, which will let us move
towards fuller (and unconditional) root register support.
Bug: chromium:860429, v8:8254
Change-Id: I8f672cf48a6ffc7bf21e7794c1b7463d7f8b9594
Reviewed-on: https://chromium-review.googlesource.com/c/1296131
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56978}
