es6/classes.js is large and causes timeouts and OOM on some of the
configurations.
Bug: v8:9246
Change-Id: Iaabfc39dd8f9554e16f67d66ce64acd3dd56b9ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704103
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62758}
Add CPU trace mark extension for adding a magic instruction like 'cpuid'
to the code stream when perform trace collection.
This feature can be enabled by --expose-cputracemark-as=THE_NAME_YOU_SPECIFIED option.
Change-Id: I33e94793cddf4956dbb3ddddf2f599420aa4a945
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1699749
Commit-Queue: Tianyou Li <tianyou.li@intel.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62749}
RepresentationChanger::GetTaggedPointerRepresentation did not handle
kCompressed cases correctly for BigInts. This led to a crash of BigInt
benchmarks in js-perf-test.
Bug: v8:9407
Change-Id: Id1d60a81afc528c8d4180bd5de9d237f2f0abd0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701848
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62718}
The bytecode graph builder may insert additional jumps for the
SwitchOnGeneratorState bytecode and for loop headers. This plays into
what the graph builder considers dead/alive. We want the serializer to
process all the bytecodes that the graph builder will process, so the
serializer needs to do something similar.
Bug: v8:7790
Change-Id: I1f1d51f4a8951149e365b3c998cef7f613bb4953
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1647694
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62712}
When passing promises from other contexts to an `await`, the
--harmony-await-optimization doesn't kick in, and as such the
promise will be wrapped in a "native promise" (from this context).
That means the promises aren't chained immediately, but delayed
via a PromiseResolveThenableJob, which chains these promises on
the next turn of this contexts' microtask queue.
If there's anything happening on the macro task queue in between
this and the point when an exception is raised, the chaining will
have happened and we actually find our way back via the promise
chains. And this CL adds support for exactly that case. For other
cases, it's currently impossible to reconstruct the async stack
unfortunately, but we hope that this will help with the major
use cases, where the developer awaits on I/O.
Bug: v8:7522, v8:8673, v8:9487
Ref: nodejs/node#28680
Change-Id: Icc06c7df12644c2d8d43b6c7580ee06bb8f1024a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701847
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62709}
This test no longer fails with concurrent inlining.
(Concurrent inlining is actually disabled in 'future' at the moment
but will be turned on again soon.)
Bug: v8:9094
Change-Id: I4d3f8021a7accff8cd670f3fef95a7995f1a9ba7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700076
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62702}
Previously, we didn't have access checks for the megamorphic case cause
we'd never get to this IC state for a receiver that doesn't hold the
right private field. But now with lazy feedback allocation we share
the megamorphic case code paths for the uninitialized loads as well,
which exposes our bug.
Bug: chromium:982702
Change-Id: I419406bcfc52575260a85d05520c1662735e15f8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697256
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62668}
This change implements lowering of speculative BigInt addition as well as
BigInt heap constants to corresponding int64 versions, if they are used in
a context where the result is truncated to the least significant 64 bits
(e.g. using asUintN). The JSHeapBroker is extended to provide access to the
BigInt's least significant digit during concurrent compilation. The BigInt
context (required to introduce correct conversions) is recognized in the
RepresentationChanger by either the output type propagated downward or the
TypeCheckKind propagated upward. This is necessary, because the TypeCheckKind
may only be set by nodes that may potentially deopt (and sit in the effect
chain). This is the case for SpeculativeBigIntAdd, but not for BigIntAsUintN.
This CL contains a simple fix to prevent int64-lowered BigInts to flow into
state values as the deoptimizer cannot handle them yet. A more sophisticated
solution to allow the deoptimizer to materialize truncated BigInts will be
added in a following CL.
Bug: v8:9407
Change-Id: I96a293e9077962f53e5f199857644f004e3ae56e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684183
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62665}
This CL adds the --assert-types flag to d8, which is intended to
insert additional runtime checks after typed nodes, verifying the
validity of our typing rules. So far, only range types are checked.
Thanks to Neil Patil for suggesting something similar.
R=neis@chromium.org, tebbi@chromium.org
Change-Id: I5eb2c482235ec8cd07ee802ca7c12c86c2d3dc40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678372
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62664}
The alignment should be 3 (i.e. 8 bytes), but was specified as 2 (i.e. 4
bytes).
Bug: v8:9425
Change-Id: I0beb09df25fe0281ed604909e894afd804f5411e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1693836
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62657}
With lazy feedback allocation and bytecode flushing we need to call
%PrepareFunctionForOptimize before we call %OptimizeFunctionOnNextCall/
%OptimizeOsr. This cl:
1. Adds an additional state in pending optimized table to check if the
optimization was triggered manually.
2. Changes the compilation pipeline to delete the entry from pending
optimized table only if the optimization was triggered through
%OptimizeFunctionOnNextCall / %OptimizeOsr.
3. Adds a check to enforce %PrepareFunctionForOptimize was called.
4. Adds a new run-time flag to only check in the d8 test runner. We
don't want this check enabled in other cases like clusterfuzz that doesn't
ensure %PrepareFunctionForOptimize is called.
Bug: v8:8394, v8:8801, v8:9183
Change-Id: I9ae2b2da812e313c746b6df0b2da864c2ed5de51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664810
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62653}
GetOwnPropertyNameTryFast uses ENUMERABLE_STRINGS filter to trigger fast
path in KeyAccumulator::GetKeys conditionally when all properties on the
receiver are enumerable. It is not easy to verify if all properties are
enumerable and the current check is incorrect in some cases.
For ex: when we have non-enumerable properties when we have elements on
the receiver. This cl removes this try_fast path from the builtin. This
could impact performance. The long term fix for this would be to fix
KeyAccumulator::GetKeys to use fast path for more cases.
Bug: chromium:977870
Change-Id: Iecde730739c2c452ffa0d893d0d1b3612a45d1b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679499
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62649}
In the atomics stress, the search for sequential sequences creates
lots of new WebAssembly.Memory objects. This memory pressure is not
central to this test, so reuse the same memory to make them less
flaky.
R=mstarzinger@chromium.org
Change-Id: I8d135e7b82d572cb1df38f37a4e2f6393f6b2e05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697247
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62644}
This adds support for properly importing {WebAssembly.Function} objects
that were constructed in JavaScript and just wrap a JavaScript callable.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I00e01db0d85b83d405eb28517d00fba62c253985
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690949
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62641}
This fixes a corner-case where a {WasmExportedFunction} that represents
a re-export of a JavaScript callable from another module was identified
correctly, but not all corner-cases were correctly covered. Concretely
we failed to check for function signatures incompatible with JavaScript.
R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-9447
BUG=v8:9447
Change-Id: Ia6c73c82f4c1b9c357c08cde039be6af100727d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690941
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62632}
This reverts commit e8d865973f.
Reason for revert: crbug.com/981701
Original change's description:
> [parsing] Improve elision of hole checks for default parameters
>
> Use the position of the next parameter to be declared as the end of the
> initializer for default parameters, so that hole checks can be elided
> for initializers using previous parameters in arrow functions.
>
> This fixes a source of bytecode mismatches when collecting source
> positions lazily.
>
> Bug: chromium:980422, v8:8510
> Change-Id: I5ab074231248b661156e7d8e47c01685448b56d5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683267
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62525}
TBR=verwaest@chromium.org,delphick@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:980422, v8:8510
Change-Id: I3abd70a1fb00967e58b46177655a0078e24db720
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697242
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62630}
This adds test coverage for calling "table.set" with a constructed
{WebAssembly.Function} object that uses a signature incompatible with
JavaScript.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I939d63db85b4eb9cffe5a901efe477397f20f925
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691917
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62616}
a77323416a missed a case when receiver is
Smi in TryPrototypeChainLookup.
Bug: chromium:980292, chromium:980226
Change-Id: Ife6be4541d6b280253a7e87cf6f57c96efe8300f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687283
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62608}
This DCHECK is unnecessary because the object can be sealed or frozen
before it is set as a prototype map.
The repro is
Object.seal(Object);// Object is HOLEY_FROZEN_ELEMENTS
const v3 = Object();
v3.__proto__ = Object; // Set prototype map bit and dictionary map bit
const v6 = Object.seal(Object); // Turn Object to DICTIONARY_ELEMENTS
Bug: chromium:980168
Change-Id: Iec50249d0ff0c5ed959201707b837871fcb88a02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687280
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62606}
The name dictionary allocated to store named captures on the regexp
result object could be too large for regular heap spaces and
ConstructNewResultFromMatchInfo must thus also handle the large object
case.
Bug: chromium:980891
Change-Id: Ia1dbecd0a9d9d6b39f80e77680386c385d95c97c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691907
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62591}
In the rare case that a tagged template is not initialized before
optimization time, we currently cache this created template in the
feedback vector. If we stop doing this, we simplify the interface
usefully for concurrent compilation and pay little for it.
Bug: v8:7790
Change-Id: Ifc82b0eb931a706767596febd4f4b312e167fd25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690837
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62590}
EscapeRegExpPattern should return a string representation of a
RegExp instance that in turn can be used to construct a new
RegExp instance with the same internal state as the original one.
Previous versions incorrectly escaped '/' also inside character classes
(e.g. /[/]/ returned "[\/]").
This patch properly escapes '/' when necessary and omits unnecessary
escapes.
Bug: v8:8615, v8:1982, v8:9446
Change-Id: I4ecb993dc69d6976f4637cedf43465cd0c32e427
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1688050
Commit-Queue: Patrick Thier <pthier@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62587}
This reverts commit 31cd5d83d3.
Reason for revert: It breaks my heart to revert this, but it fails differently on several bots, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/26671.
Original change's description:
> [arraybuffer] Rearchitect backing store ownership
>
> This CL completely rearchitects the ownership of array buffer backing stores,
> consolidating ownership into a {BackingStore} C++ object that is tracked
> throughout V8 using unique_ptr and shared_ptr where appropriate.
>
> Overall, lifetime management is simpler and more explicit. The numerous
> ways that array buffers were initialized have been streamlined to one
> Attach() method on JSArrayBuffer. The array buffer tracker in the
> GC implementation now manages std::shared_ptr<BackingStore> pointers,
> and the construction and destruction of the BackingStore object itself
> handles the underlying page or embedder-allocated memory.
>
> The embedder API remains unchanged for now. We use the
> v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> keep the backing store alive properly, even in the case of aliases
> from live heap objects. Thus the embedder has a lower chance of making
> a mistake. Long-term, we should move the embedder to a model where they
> manage backing stores using shared_ptr to an opaque backing store object.
>
> R=mlippautz@chromium.org
> BUG=v8:9380,v8:9221
>
> Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62572}
TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,titzer@chromium.org,gdeepti@chromium.org,mlippautz@chromium.org
Change-Id: Ib35788ba8c31192d90cbc72df3dbc41030f109de
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9380, v8:9221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691034
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62578}
This CL completely rearchitects the ownership of array buffer backing stores,
consolidating ownership into a {BackingStore} C++ object that is tracked
throughout V8 using unique_ptr and shared_ptr where appropriate.
Overall, lifetime management is simpler and more explicit. The numerous
ways that array buffers were initialized have been streamlined to one
Attach() method on JSArrayBuffer. The array buffer tracker in the
GC implementation now manages std::shared_ptr<BackingStore> pointers,
and the construction and destruction of the BackingStore object itself
handles the underlying page or embedder-allocated memory.
The embedder API remains unchanged for now. We use the
v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
keep the backing store alive properly, even in the case of aliases
from live heap objects. Thus the embedder has a lower chance of making
a mistake. Long-term, we should move the embedder to a model where they
manage backing stores using shared_ptr to an opaque backing store object.
R=mlippautz@chromium.org
BUG=v8:9380,v8:9221
Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62572}
When I implemented these instructions, I copied the naming scheme of
{GetGlobal}. That's not appropriate for the table.get instruction
though, and I decided I suffered enough from that bad name now.
R=clemensh@chromium.org
Bug: v8:7581, v8:9396
Change-Id: Id1796425458f3d06a2da774374f02c49d665d2c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690835
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62563}
This adds a test case for using constructed {WebAssembly.Function}
objects in non-zero tables. Due to a recent refactoring that unifies
handling of dispatch tables, this works out of the box. The test
coverage however is still useful, since code paths are slightly
different for non-zero tables.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection-with-anyref
BUG=v8:7742
Change-Id: I0cf4b0a8039bbef0422b06ee23744a949be8f1b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690821
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62555}
This is a reland of 89d93e3851
Original change's description:
> Reland "Let all early errors be SyntaxErrors."
>
> This is a reland of 99fd5b9b9d which includes a missed update to
> test/test262/test262.status.
>
> Implement the spec change from the following TC39 PR:
> https://github.com/tc39/ecma262/pull/1527
>
> Bug: v8:9326
> Change-Id: Ie3aac60db550e90fb648fc30886a05419fa41afe
> TBR: adamk@chromium.org
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682989
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62500}
Bug: v8:9326
Change-Id: Ic30280400dfa5b83a4a397888e563eee479446c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1688271
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62553}
This CL teaches the deoptimizer about JavaScriptBuiltinContinuation
frames that are not preceded by argument adapter frames. This pattern
is used when calling C++ API functions from TurboFan.
This CL fixes a crash when the deoptimizer encounters the pattern
described above. The crash was caused when the deoptimizer tried to
read the arguments of the continuation frame. As no adapter frame
was present, the argument count was read from the SharedFunctionInfo
which had the kDontAdaptArgumentsSentinel value. This translated to
an argument count of ~65000 later down the line, which caused a
FATAL error when the deoptimizer tried to re-construct ~65000
non-existent values.
Bug: chromium:980529
Change-Id: Id2de3bf7607102ab5a16de344c649015e968b185
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687417
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62547}
Use the position of the next parameter to be declared as the end of the
initializer for default parameters, so that hole checks can be elided
for initializers using previous parameters in arrow functions.
This fixes a source of bytecode mismatches when collecting source
positions lazily.
Bug: chromium:980422, v8:8510
Change-Id: I5ab074231248b661156e7d8e47c01685448b56d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683267
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62525}
This adds a test checking whether function identity is preserved upon
re-export of various function kinds. The tests are expected to all pass
and just increase code coverage.
R=ahaas@chromium.org
TEST=mjsunit/wasm/export-identity
Change-Id: I4fbb7db2d78c7ffeb6278d6b6d87a7c029326387
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687893
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62516}
This assertion was borked, as it accepted obviously "same" values like
the same object. This fixes the predicate by switching both assertSame
and assertNotSame to use {Object.is} underneath. It also adds a new
respective regression test (gotta test the tester).
R=ahaas@chromium.org
TEST=message/mjsunit/fail/assert_not_same
Change-Id: I6ba20c4b8b96a736ab924715b1cad78f2f43a120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687541
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62512}
This reverts commit 89d93e3851.
Reason for revert: Breaks layout tests: https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064/32929
Original change's description:
> Reland "Let all early errors be SyntaxErrors."
>
> This is a reland of 99fd5b9b9d which includes a missed update to
> test/test262/test262.status.
>
> Implement the spec change from the following TC39 PR:
> https://github.com/tc39/ecma262/pull/1527
>
> Bug: v8:9326
> Change-Id: Ie3aac60db550e90fb648fc30886a05419fa41afe
> TBR: adamk@chromium.org
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682989
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62500}
TBR=adamk@chromium.org,gsathya@chromium.org,verwaest@chromium.org,rkirsling@gmail.com
Change-Id: Ia56dcda6780a2b1249749e1e7978b35b5e33fbcf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9326
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687678
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62509}
"Operand(num_saved_registers_)" might be bigger than 16 bits. Using a 32/64 bit load/mov
instruction to overcome the problem.
Port 4c156936e8
Original Commit Message:
Large regexp results may exceed kMaxRegularHeapObjectSize and must
thus be allocated in large object space.
R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ibfaf6150a139427f073f5f11873ad5832fc328ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1685027
Auto-Submit: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#62507}
Before running OOM on a wasm memory allocation, we trigger a GC, but
only in the isolate which allocates the new wasm memory. Hence if
multiple isolates are involved, we can run OOM anyway. This is a rare
case which did not cause trouble yet in the wild, so skip that test on
the 'isolates' bot for now.
R=ahaas@chromium.org
Bug: v8:9405
Change-Id: Ieb29a62e85db115320ae269e89d3e1fc451fd915
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1685793
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62505}
This add signature checking when a constructed {WebAssembly.Function} is
being imported into a module. Signatures must match exactly. Note that
importing itself is not yet implemented and will be done as a follow-up.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Iaa3fee574f8edafdddfc9e7aafe2bbd1ae597ff2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683729
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62502}
This is a reland of 99fd5b9b9d which includes a missed update to
test/test262/test262.status.
Implement the spec change from the following TC39 PR:
https://github.com/tc39/ecma262/pull/1527
Bug: v8:9326
Change-Id: Ie3aac60db550e90fb648fc30886a05419fa41afe
TBR: adamk@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682989
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62500}
Negating the maximum int32 failed in ubsan. Use
{base::NegateWithWraparound} to avoid UB.
R=jkummerow@chromium.org
Bug: chromium:980007
Change-Id: If52a3bb3158eb5b465e7bd29deaffc0b18660360
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683993
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62470}
This fixes undefined behavior in the implicit cast from double to float
when a double literal is passed through {fround} while declaring a local
variable.
R=jkummerow@chromium.org
TEST=mjsunit/regress/regress-crbug-976934
BUG=chromium:976934
Change-Id: I0efa2bf3f89d32c445f0b9bf719880d17fe9743c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683999
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62469}
This reduces the time it takes to run this test in --jitless mode
from 32s to 0.7s.
Bug: v8:9416
Change-Id: Ie9a7465b604b28ff8ccaa50f0918c62e3128ac08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682575
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62464}
Since https://codereview.chromium.org/2777583003, the Boyer-Moore
lookahead (used by the irregexp engine) also looks inside submatches
to narrow down its range of accepted characters at specific offsets.
But the end of a submatch, designated by a PositiveSubmatchSuccess
action node, was not handled correctly. When a submatch terminates,
we have no knowledge of what may follow, and thus must accept any
character at following positions. This is done by the SetRest call
added in this CL.
An example, since this is fairly obscure:
/^.*?Y(((?=B?).)*)Y$/s
The initial non-greedy loop, together with the s flag,
will trigger an attempted Boyer-Moore lookahead. After this follows
an unconditional Y, a *-quantified loop matching any char and
containing a lookahead that matches either 1 B or 0 B's, and an
unconditional trailing Y.
When the BM lookahead scans the subject string for the beginning of
this pattern after the non-greedy loop, it should look for: a Y at
offset 0, and either a B, a Y, or '.' (-> any character) at offset 1.
Prior to this CL this was not the case:
- The lookaround is internally generated as a submatch.
- The optional 'B?' is unrolled into 'either B followed by submatch
end' or 'submatch end'.
- Filling in BM infos terminates when encountering a submatch end.
Thus in the former case we added B to the set of accepted characters
and terminated, while in the latter case we simply terminated.o
This CL ensures that BM will accept any character at any offset at or
exceeding the first encountered submatch end.
Bug: v8:8770
Change-Id: Iff998ba307cd9669203846a9182798b8cf6a85dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679506
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Erik Corry <erikcorry@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62460}
regress-976627 is pass and should pass on mips64el,
see 4c15693https://crrev.com/c/1674027
Change-Id: I4da905ea129a78988d75e5b19cca3a4e5a17fdcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679960
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Yu Yin <xwafish@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62459}
The previous fix for this bug (crrev.com/c/1678365) pessimistically
would mark all shadowed variables as maybe_assigned. Unfortunately,
this doesn't work across a parse/preparse boundary, where the shadowing
variable is found via Scope::AnalyzePartially while the shadowed
variable is outside of the preparser entry point. In those cases, the
referencing proxy is copied to the outer scope, in which case the
dynamicness of the original lookup is lost and the maybe_assigned
pessimisation no longer applies.
This means that maybe_assigned status of a variable is dependent on
which function is being parsed. In particular, it can cause bytecode
to change on recompilation, causing issues for lazy source positions.
This patch allows SetMaybeAssigned to walk its shadowed variables,
and recursively set them to maybe_assigned too. Checking for
maybe_assigned changing prevents this recursion from having a
quadratic performance failure mode.
Bug: v8:8510
Bug: v8:9394
Change-Id: Id19fe1fad5ec8f0f9aa03b00eb24497f88f71216
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677265
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62458}
When applying Object.seal(), Object.freeze() to Smi, Double elements
kind, it will transition to Object elements kind first then to new
frozen, sealed elements kind accordingly.
Also, add more mjsunit.
Bug: v8:6831
Change-Id: I454b42d7eb329b03e20245896641eb6c1a87831d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662657
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62457}
Implement the spec change from the following TC39 PR:
https://github.com/tc39/ecma262/pull/1527
Bug: v8:9326
Change-Id: I9639903b12e7621e323990e2335f00e0313a59c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1643171
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62451}
GetPropertyWithReceiver is similar to GetProperty, except that additional receiver parameter is used in TryPrototypeChainLookup to support GetPropertyWithReceiver stub.
We only use this stub in ProxyGetProperty builtin for now.
Bug: v8:8958
Change-Id: Ied60e4f6ee6e09bca2f161048b481a0bf37a78a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1676879
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62431}
d8 treats files with the .mjs extension as modules instead of
classic scripts. Thus, the `// MODULE` pragma and its corresponding
logic in test runners can be removed in favor of explicitly adding
the extension.
Bug: v8:7950, v8:9395, v8:9406
Also-By: tmrts@chromium.org
Change-Id: Ic74328dc5c5f176bb4bdf6d74bdd4d3966279ba5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1675958
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Auto-Submit: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62421}
If there was an assignment to a maybe-shadowing dynamic variable,
then the shadowing variable would be marked maybe_assigned, but the
maybe-shadowed variable would stay unchanged. This meant that in
non-shadowing cases, the not-actually-shadowed variable would have
the wrong maybe_assigned state, and e.g. would break context
specialization.
This patch pessimistically unconditionally sets maybe_assigned on
variables shadowed by a dynamic variable in a `with` scope. This
marking can cause false positives and sub-optimal optimization for
some functions with 'with' blocks, but it's also the simplest fix
for this issue which doesn't affect performance in the common case
of no 'with' blocks.
Bug: v8:9394
Change-Id: I6924bd7d48dda61232aa9d72c39df1c76c665c67
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678365
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62407}
Boilerplate values may possess an unboxed double field filled with the kHoleNan64Int sentinel value, which indicates that the field is uninitialized. When a boilerplate value migrates away from the unboxed double representation to a tagged one, we should replace the sentinel value by the proper uninitialized oddball value.
This fixes an issue with JSCreateLowering::AllocateFastLiteral not detecting const stores of uninitialized values properly.
R=bmeurer@chromium.org, jarin@chromium.org
Bug: chromium:976598
Change-Id: I6bb216c0618a3105e6c8cfc04b1900d2f83a52ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674034
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Schmid <gsps@google.com>
Cr-Commit-Position: refs/heads/master@{#62394}
According to spec https://tc39.es/ecma262/#sec-object.preventextensions, the commit 8e0ef9b9a0 is missing the last step when object is proxy, it needs to return the object.
var proxy = new Proxy({}, {});
var object = Object.preventExtensions(proxy);
proxy === object; // should be true
Also, add mjsunit test.
Bug: v8:6664
Change-Id: Ic3688519539f8903ee0bc7e885905a86d195a4db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1668443
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62393}
This is a reland of 5ff38bae08
Original change's description:
> [TurboFan] Fast path for JSAdd with BigInt feedback
>
> This CL introduces the necessary infrastructure to generate speculative
> BigInt operations in case of BigInt feedback. In particular, the JSAdd
> operator is lowered to a speculative call to the BigIntAdd builtin,
> with a deopt bailout in case of exceptions or violated assumptions.
>
> Bug: v8:9213
> Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916
> Commit-Queue: Nico Hartmann <nicohartmann@google.com>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62362}
Bug: v8:9213
Change-Id: Ic0caf7aab2103b8f5e22a504427e8604cc894d75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677209
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Cr-Commit-Position: refs/heads/master@{#62381}
Deprecated maps might not be updated before being passed to
PrepareForDataProperty. If the target map is a dictionary map,
then adding the data property can fail.
As a drive-by, remove the dead ForTransitionHandler code, which
was another (potentially unsafe) caller of PrepareForDataProperty
Bug: chromium:977012
Change-Id: I894bbc9bca2001555474a3570eb03fe6b0f69ddd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674029
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62377}
Large regexp results may exceed kMaxRegularHeapObjectSize and must
thus be allocated in large object space.
Drive-by: Rename '%InNewSpace' to '%InYoungGeneration'.
Bug: chromium:976627
Change-Id: I38b5aecb95a95cf2fdbb24d19550cec34361a09d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674027
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62368}
This reverts commit 5ff38bae08.
Reason for revert: flaky test that is not normally flaky failed.
See: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20nosnap%20-%20debug/24531
Original change's description:
> [TurboFan] Fast path for JSAdd with BigInt feedback
>
> This CL introduces the necessary infrastructure to generate speculative
> BigInt operations in case of BigInt feedback. In particular, the JSAdd
> operator is lowered to a speculative call to the BigIntAdd builtin,
> with a deopt bailout in case of exceptions or violated assumptions.
>
> Bug: v8:9213
> Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916
> Commit-Queue: Nico Hartmann <nicohartmann@google.com>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62362}
TBR=jarin@chromium.org,neis@chromium.org,sigurds@chromium.org,nicohartmann@google.com
Change-Id: I5ae63a0183283894b6d1130792ab37a95b014550
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9213
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1676607
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62364}
This CL introduces the necessary infrastructure to generate speculative
BigInt operations in case of BigInt feedback. In particular, the JSAdd
operator is lowered to a speculative call to the BigIntAdd builtin,
with a deopt bailout in case of exceptions or violated assumptions.
Bug: v8:9213
Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62362}
In this bug, we might replace a phi node with the Dead node even though
it still has uses. DeadCodeElimination picks this up and inserts a
runtime crash into the code.
Bug: chromium:974474
Change-Id: Iea685913c8666806972719bbfb0891e516207d4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669693
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62352}
We currently use the class name “JSValue” for JSObjects that wrap
primitive values. This name is a common source of confusion. This patch
switches to a name that’s more clear.
In addition to manual tweaks, the patch applies the following mechanical
global replacements:
before | after
--------------------------------|--------------------------------------
if_valueisnotvalue | if_valueisnotwrapper
if_valueisvalue | if_valueiswrapper
js_value | js_primitive_wrapper
JS_VALUE_TYPE | JS_PRIMITIVE_WRAPPER_TYPE
JSPrimitiveWrapperType | JSPrimitiveWrapper type
jsvalue | js_primitive_wrapper
JSValue | JSPrimitiveWrapper
_GENERATED_JSVALUE_FIELDS | _GENERATED_JSPRIMITIVE_WRAPPER_FIELDS
Change-Id: I9d9edea784eab6067b013e1f781e4db2070f807c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672942
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62337}
We have a global test/OWNERS that has "file://COMMON_OWNERS".
This CL removes redundant OWNERS files in test/ subdirectories and
removes redundant entries from OWNERS files we need to keep for
special per-file entries.
R=yangguo@chromium.org, machenbach@chromium.org
CC=jkummerow@chromium.org
Bug: v8:9247
Change-Id: Ic2e8cbe8e379d7d23c86c6164305e65807f28ed3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674024
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62336}
We tried to pass the load mode even for stores.
Bug: chromium:977670
Change-Id: I2527a5ca755dba343b75f54383d17e22be0a20a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672940
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62333}
The table.copy instruction used the indirect_function_table_size field
of the instance for bounds-checks. However, when Table 0 is of type
anyref, this field is not set. Now we use the actual size of the table
instead.
R=clemensh@chromium.org
Bug: chromium:977101
Change-Id: Idda9cfe228141877747ed9a824936a1232f58cf8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669695
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62315}
Makes the order of the generated calls to the Runtime function
DefineAccessorPropertyUnchecked fixed regardless of hashseed so that
recompilation for lazy source positions always generates the same
result.
Moves AccessorTable from src/ast/ast.h to bytecode-generator.cc since
that's the only place that uses it.
Bug: v8:9383, v8:8510
Change-Id: I89e0aad1683a793714bfb48eca1b00abe20cad0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669689
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62303}
This patch implements the access of private methods:
- When building property loads, check whether it requires
a brand check. If so, build the brand check and load the
property (the method) from the context instead.
- Throw type errors when there is an attempted write to private
methods.
Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
Bug: v8:8330
Change-Id: Ic917d2a0030196c1940b0c0ba65a340af736c769
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1610383
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62292}
A class's fields can appear twice in the class AST, via the properties
array and the synthetised initializer method. This means that the
reindexer can end up visiting the same function literal twice, since the
T in AST is no longer a T but rather a DAG.
Now, we special case the class visitor in the reindexer to avoid these
double visits where appropriate. We know what kinds of fields can be
double visisted, so we don't need a visited set, but we now also have
one for debug builds to verify that each function is visited exactly
once.
Bug: chromium:974627
Change-Id: Ib531becc6e3f3c73f420b5fb49790fe4a2022d65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1667003
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62282}
This CL changes the generic version of Array#sort to use 'strict'
DeleteProperty when "moving" holes to the end of the sort range.
This brings V8 not only in line with the proposed Array#sort spec
change, but also closer to what other engines do. Now all engines
throw a TypeError when the new test case is run.
R=jgruber@chromium.org, mathias@chromium.org
Bug: v8:8714
Change-Id: Ic5bcd152ad55fd534c1e9e3218393bfe4a50667e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666995
Commit-Queue: Simon Zünd <szuend@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62273}
This CL fixes a flaky mjsunit test, that exercises Array#reduce with
sealed arrays in TurboFan. The flake was caused by temporary objects,
whos maps didn't live long enough. The code object of the function
under test holds weakly onto this maps. With a low enough gc interval,
the maps, and thus the code object, get cleaned up before the
{assertOptimized} can execute.
The fix is simply to assign these temporary objects to variables.
Bug: v8:9374
Change-Id: I43da8ba6b0194872b176e27617d9ca7fbfe43ec2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666989
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62269}
CL https://chromium-review.googlesource.com/c/v8/v8/+/1660623
("[Turbofan] Brokerize more promise reductions in JSCallReducer")
introduced a bug where we bail out of a call reduction but failed
to remove graph constructs added by the MapInference class.
R=jarin@chromium.org
Bug: chromium:976256, chromium:976524
Change-Id: I97f142fe6c1caba5e679f7df742893536c83b2d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666990
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62267}
We don't want to handle even non-growing stores when there are TypedArrays
in the prototype chain. Typed arrays handle the out-of-bounds accesses by
ignoring the stores unlike the regular array writes. We just let runtime
handle these cases instead of making ICs more complex.
There was an earlier cl (https://chromium-review.googlesource.com/c/v8/v8/+/1609790)
that fixed it for growing stores. This cl extends it for non-growing stores
as well to handle more cases.
Bug: chromium:961709
Change-Id: I65e079b88c10d2ba343f69a67134893319cd8f8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662305
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62243}
This adds missing support when converting a Word32 value (either in
Signed32 or Unsigned32 range) to Word64 representation, for which the
type also includes MinusZero. This conversion is fine as long as the
difference between 0 and -0 is not observable (in other words, as long
as the truncation identifies zeros).
Bug: chromium:971782, chromium:225811, v8:4153, v8:7881, v8:8171, v8:8383
Change-Id: I9d350a25f57b1342eb7fd1279d55a8610bdaf7cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664062
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62235}
This adds preliminary support for storing constructed WebAssembly
functions in tables. Note that for now only tables at index #0 are
supported, extending it to other tables indexes will be done as a
follow-up.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I9aa07813e07f0ceb4eafe37af412b45c7d235722
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1640209
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62210}
RegExp assertions (e.g.: '^', '$', '\b', ...) sequences have certain
properties that this rewriter exploits:
1. They are zero-width and order-independent, thus one can remove all
duplicate assertions.
2. If a subsequence is guaranteed to fail, the entire sequence fails.
Any sequence always known to fail (e.g. containing both '\b' and '\B')
can be rewritten to a single node that triggers failure.
This CL generalizes the previous optimization for repeated assertions
to be order-independent, i.e. assertions only have to be in the same
sequence but not next to each other.
Bug: v8:6515, v8:6126
Change-Id: I3f92f081ce8a55ad8c34c269a09a6686e3b008f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657925
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62201}
When iterating over the holdings inside the cleanup callback,
we could potentially unregister the weakref which is next or
prev on the key list causing these checks to be incorrect.
Bug: v8:9360, v8:8179
Change-Id: I53ea12346eb4882b16a82677b64ba2c756d23a1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1658161
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62165}
Disable bytecode flushing for test as it messes up lazy source
positions and the flags aren't representative anyway.
Bug: v8:8510
Change-Id: I6d5bc8dcd174a9bfc48f682518e6c62d79acb691
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1658152
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62155}
The store element handlers don't check if the array length is writable
before updating the length. Since this is not expected to be a common
case no need of handling this in the element handlers. Just moving to
megamorphic would be sufficient.
Bug: chromium:967104
Change-Id: I7a7f9ea768266b9ffd6289328d61d2297d455619
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1658154
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62152}
ObjectPreventExtensions and ReflectPreventExtensions are now Torque builtins (previously CPP) and the Proxy path is implemented completely in Torque while everything else calls into runtime (and is thus a bit slower than previously).
Perf improvement in micro-benchmark JSTests/Proxies
Before:
PreventExtensionsWithoutTrap-Proxies(Score): 1978
PreventExtensionsWithTrap-Proxies(Score): 739
After:
PreventExtensionsWithoutTrap-Proxies(Score): 3017
PreventExtensionsWithTrap-Proxies(Score): 2044
Bug: v8:6664
Change-Id: I6505d730cea6b0d197f6f5d0540b39056c8b763d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1652688
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62130}
Make sure to use the callback passed to cleanupSome
Bug: v8:8179
Change-Id: Ia5d90b56edf80e05bdaf0dc520b555c29042b64c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655306
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62122}
With bytecode flushing and lazy feedback allocation, we need to call
%PrepareForOptimization before we call %OptimizeFunctionOnNextCall,
ideally after declaring the function.
Bug: v8:8801, v8:8394, v8:9183
Change-Id: I3fb257282a30f6526a376a3afdedb44786320d34
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648255
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62119}
Currently, in wasm-function stack traces, v8 displays the decimal offset
from the start of the function. However, the WebAssembly WebAPI
specification says that it should be a hex offset into the module.
This change makes the stack trace display with hex module offsets, as
well as fixing all the unit tests that depended on the old behaviour.
R=fgm@chromium.org, titzer@chromium.org, yangguo@chromium.org
Bug: v8:9172
Change-Id: I73737a319a42dd665521ab8a4b825199ae11c87f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1646846
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Guanzhong Chen <gzchen@google.com>
Cr-Commit-Position: refs/heads/master@{#62103}
It was a good flag, but it's time to say goodbye. Let us take a moment
to remember the good times we've had during its short time on earth.
It shipped in Chrome 74.
BUG=v8:8523
R=adamk@chromium.org, mathias@chromium.org, gsathya@chromium.org
Change-Id: I37e58360614c0bb3582b8bbfac795d5ed3e5a149
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1641205
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Auto-Submit: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#62099}
An error object's 'stack' property is lazily formatted once the
property is first read. It is thus possible that lazy formatting
happens in a different realm than where the error object was
constructed.
In this case, we should use the origin-realm's prepareStackTrace
function to format the stack trace.
This CL implements that behavior by fetching prepareStackTrace from
the given error object's context's error function.
Bug: v8:7848
Change-Id: Ibc383cf24f2c0dab2fd8bb7bc740f1488d9954a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1113438
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62090}
This CL adds two mjsunit tests that transition an error object to
dictionary mode before and after Error.stack is formatted and verify
that the custom 'stack' property accessor works as intended.
Bug: v8:8742
Change-Id: I4beb52c75b94533c10fac007f41117ab8915fac8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649789
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62078}
Quotes have been added around the token to make the message clearer.
Bug: chromium:943636
Change-Id: Ic38f3e6d307157af2c0146e69fb611a2cfb46564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593307
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62074}
The path for sealed elements is handled by using the same path for SmiOrObjectElementKind, just need to extend a DCHECK in CodeStubAssembler::IsFixedArrayWithKind.
The only special case is when we write to a hole in holey sealed elements. Since we can not write in that case, just bail out.
Bug: chromium:967101
Change-Id: Ibf837ae053fe609bca83da432f298ef056f3aced
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632830
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62071}
The CloneObject bytecode was only able to handle objects, null and
undefined, and explicit bytecode had to be generated to perform the
ToObject outside the bytecode (unlike the other IC bytecodes that
just perform the ToObject implicitly). That means the simplest possible
object cloning would also generate a sequence of 5 bytecodes (at least):
```
Mov <register>, a0
JumpIfNull @1
JumpIfUndefined @1
ToObject <register>
1: CloneObject <register>
```
That is quite wasteful and unnecessary, since the core logic in the
runtime already does the ToObject properly anyways. This change
refactors the CloneObjectIC slightly to behave more like the other ICs
and do the ToObject implicitly when necessary.
Bug: v8:7611, v8:9114, v8:9183, v8:9343
Change-Id: I11973e90bf875f154a5a7739287bee17041e4a7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649554
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62064}
The DoubleToFloat32 helper takes care of everything, so use it
consistently.
Bug: chromium:969498
Change-Id: If71e5374684b89615006548cb0329f4d4cb7fd6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648253
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62062}
As per the new specs, when the exception is thrown by iterator's return method
while doing iterator close because it is not callable, the exception is
suppressed in the same way as if the return method is called and threw an exception.
https://github.com/tc39/ecma262/issues/1398
Bug: v8:9056
Change-Id: I21abd5fdd01d3a957c3c16d9d3aaab9091e43142
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648256
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#62035}
We need to hold onto the bytecode array so it doesn't get flushed.
Bug: v8:8394
Change-Id: Ia583a0a662740e369fcbc1c94041895e463be26e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645329
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62011}
ObjectIsExtensible is now a Torque builtin (previously CPP) and the Proxy path is implemented completely in Torque while everything else calls into runtime (and is thus a bit slower than previously).
Improvement in micro-benchmark
Before:
IsExtensibleWithoutTrap-Proxies(Score): 2228
IsExtensibleWithTrap-Proxies(Score): 917
After:
IsExtensibleWithoutTrap-Proxies(Score): 3683
IsExtensibleWithTrap-Proxies(Score): 3310
Bug: v8:6664
Change-Id: I1fbe1c51cb724a23d7a59fc8231bb3d1461a6add
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1637444
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62006}
With bytecode flushing and lazy feedback allocation, we need to call
%PrepareForOptimization before we call %OptimizeFunctionOnNextCall,
ideally after declaring the function.
Bug: v8:8801, v8:8394, v8:9183
Change-Id: I6bf119e726426df8527d97546b6ce806112c894d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1643167
Auto-Submit: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61988}
Array push / pop / shift were inlined if the elements kind of the
receiver maps is the same. This cl extends it by inlining these
builtins even when the receiver maps have different elements kinds.
It still limits it to only fast elements kinds. This is required to
prevent regressions in deltablue when lazy feedback allocation is
enabled. With lazy feedback allocation we may see polymorphic
feedback more often, since we don't have allocation site feedback
till the feedback vectors are allocated.
Bug: v8:9078
Change-Id: Id4a7b84be6305b125913b6ce0fb4f3eb3e3b15ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632239
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61949}
Bug: v8:9247
Change-Id: Id6860e7b0f932990ac3cda39e369b0809e4f6a2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632072
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61928}
Currently, Number.prototype.toString(radix) often fails to produce the
least significant bit for doubles near zero. For example, for the
minimum double, 5e-324, toString(2) produces "0". This means that a
user cannot reliably get the exact binary or hexdecimal value of a
double from JavaScript using toString.
This patch makes a slight amendment to the DoubleToRadixCString
function, so that doubles where the gap to the next double is 5e-324
(i.e. doubles less than 2**-1021), are represented exactly in binary and
other power-of-two bases, and close to exactly otherwise. It results
in Number.prototype.toString producing the correct binary value for all
doubles.
R=jkummerow@chromium.org, mathias@chromium.org, yangguo@chromium.org
Bug: v8:9294
Change-Id: I71506149b7c4c0eac8c38675a1ee15fb4f36f9ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631601
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61925}
According to the spec, in case where the property is non-configurable and
non-writable, the value passed to the set trap should be compared to the data.
Instead, the trap result was compared, because of the misleading name of the
CheckGetSetTrapResult parameter.
Regression was introduced in
https://chromium-review.googlesource.com/c/v8/v8/+/1604071
Bug: chromium:966450
Change-Id: I77501980475da3aeb4f6153321da39e6fc2e6bd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632238
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61916}
This is a reland of 8092acbe41
Original change's description:
> [wasm] Store signature with {WebAssembly.Function} objects.
>
> This adds simple serialization and deserialization of the signature
> provided when a {WebAssembly.Function} object is constructed. For now
> this signature is only used by the {WebAssembly.Function.type} method,
> but will soon be used when importing such functions as well.
>
> R=jkummerow@chromium.org
> TEST=mjsunit/wasm/type-reflection
> BUG=v8:7742
>
> Change-Id: If4a687ea537d8c12f4f01a7d3ac5a795ceb999c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632211
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61898}
Bug: v8:7742
Change-Id: I5d784165c460abd9d7b07f5cdafc746d5380ccd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632159
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61910}
On Android libraries there are zero length entries within the ranged
symbols which break our range processing. This updates the logic to
only add entries for zero-length entries if they aren't within the range
of the previously added entry.
Change-Id: I511a6221817c535d967a50413948a29d9deb1e85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627985
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61903}
This reverts commit 8092acbe41.
Reason for revert: Causes UBSan warnings:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/6436
Original change's description:
> [wasm] Store signature with {WebAssembly.Function} objects.
>
> This adds simple serialization and deserialization of the signature
> provided when a {WebAssembly.Function} object is constructed. For now
> this signature is only used by the {WebAssembly.Function.type} method,
> but will soon be used when importing such functions as well.
>
> R=jkummerow@chromium.org
> TEST=mjsunit/wasm/type-reflection
> BUG=v8:7742
>
> Change-Id: If4a687ea537d8c12f4f01a7d3ac5a795ceb999c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632211
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61898}
TBR=jkummerow@chromium.org,mstarzinger@chromium.org
Change-Id: I56ea9df5db3f95c05068186097e298cb73a3675d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7742
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632218
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61899}
This adds simple serialization and deserialization of the signature
provided when a {WebAssembly.Function} object is constructed. For now
this signature is only used by the {WebAssembly.Function.type} method,
but will soon be used when importing such functions as well.
R=jkummerow@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: If4a687ea537d8c12f4f01a7d3ac5a795ceb999c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632211
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61898}
Feedback pollution can create situations in which we statically see stores to the same field with incompatible representations; dynamically this should be impossible for a single TurboFan compilation unit. Instead of failing an assertion we produce Unreachable nodes.
R=tebbi@chromium.org
Bug: chromium:967434 chromium:967506
Change-Id: Id549ec84f28b4fed2d2e5ef05b40b48bc5b30e97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632169
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61894}
This is a quick fix for the recent bailout-on-uninitialized feature of
the serializer, which does not work with resumables. For now, simply
treat the ResumeGenerator bytecode as if it was an exception handler
entry point. I want to revisit this later because the proper fix might
be to teach the serializer about the SwitchOnGeneratorState bytecode.
Bug: chromium:966560, v8:7790
Change-Id: I48bc6ba7299faa29802159cc7c36f4629667b5d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630670
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61877}
This is a reland of 4b86fea530 with
copy&paste typo in CodeStubAssembler::AllocateByteArray() fixed
(bug led to holes in new space, which was crashing reproducibly
on the ia32 bot).
Original change's description:
> [typedarray] Move external/data pointer to JSTypedArray.
>
> As the next step in supporting huge typed arrays in V8, this moves the
> external/data pointer from the FixedTypedArrayBase backing store to the
> JSTypedArray instance itself, and replaces the special backing stores
> with a plain ByteArray (removing all the code for the FixedTypedArrayBase
> class hierarchy). By doing so, we can drastically simplify the system
> around typed arrays.
>
> Note: Several places in the code base used to check the instance type
> of the elements backing store of a JSTypedArray instead of checking the
> elements kind on the JSTypedArray map directly. Those had to be fixed,
> since the backing store is now always a ByteArray.
>
> Drive-by-fix: Move all the typed elements access related code into the
> elements.cc file to properly encapsulate the accesses.
>
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
> Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
> Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61855}
Tbr: petermarshall@chromium.org
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Change-Id: I87fcdb28532c5f08cc227332a4d59546cb423810
Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
Cq-Include-Trybots: luci.v8.try:v8_linux_shared_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631592
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61864}
This adds a reflective function to retrieve the function type of an
exported or constructed WebAssembly function object. Note that this
first implementation only supports exported functions for now, the
support for constructed functions will be done as a follow-up.
R=jkummerow@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I38a16972d8437521993992ca20887c47c7c6b99b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627989
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61851}
When allocating large arrays on 32-bit systems, the length conversion
caused the work array capacity to become negative. As the sort range
is currently clamped at kSmiMaxValue anyway, the fix is to also
clamp the work capacity to that value.
R=jgruber@chromium.org
Bug: chromium:967065
Change-Id: I9ea60464c5b7f3796c5389cbaf668b990eddecf6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630672
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61845}
This is a reland of e588ff10e5
The only change over the original CL is found in JSCreateLowering::AllocateFastLiteral. We now guard against boilerplate values for unboxed double fields that *look* like legitimate initial values, but should really be kHoleNanInt64 instead.
The underlying problem certainly existed before, but an invariant added to LoadElimination in this CL caused a Chromium layout test to fail. The change in this reland is therefore a workaround, the root cause remains to be fixed. Specifically, we find that a pointer to the undefined value oddball is sometimes reinterpreted as a double and assigned as a boilerplate value. @jarin suspects that this stems from in-place map updates.
Original change's description:
> Make LoadElimination aware of const fields (Part 2; stores)
>
> Adds const information to store field accesses and uses it in load elimination
>
> Change-Id: I00765c854c95c955dabd78557463267b95f75eef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611543
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Schmid <gsps@google.com>
> Cr-Commit-Position: refs/heads/master@{#61796}
Change-Id: Ie388754890024a3ca7d10c9d4d7391442655b426
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630676
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Schmid <gsps@google.com>
Cr-Commit-Position: refs/heads/master@{#61838}
COW arrays were previously handled in the C++ pre-processing runtime
function. The Torque version forgot a "EnsureWritableFastElements".
This CL fixes that.
Bug: chromium:967254
Change-Id: Ifbf89e57cfe724e61316b8abc226f7e8a262fce2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630675
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61835}
This is a reland of 2b0ac2fb9f
The layout test that caused this revert was fixed with:
https://crrev.com/c/1627386
Original change's description:
> [array] Move Array#sort pre-processing to Torque
>
> This CL removes the "PrepareElementsForSort" runtime function, and
> replaces it with a simpler version in Torque. The biggest difference
> is that certain sparse configurations no longer have a fast-path.
>
> The Torque pre-processing step replaces the existing Torque mechanism that
> copied already pre-processed elements into the "work" FixedArray. The Torque
> compacting works as follows:
> - Iterate all elements from 0 to {length}
> - If the element is the hole: Do nothing.
> - If the element is "undefined": Increment undefined counter.
> - In all other cases, push the element into the "work" FixedArray.
>
> Then the "work" FixedArray is sorted as before. Writing the elements from
> the "work" array back into the receiver, after sorting, has three steps:
> 1. Copy the sorted elements from the "work" FixedArray to the receiver.
> 2. Add previously counted number of "undefined" to the receiver.
> 3. Depending on the backing store either delete properties or
> set them to the Hole up to {length}.
>
> Bug: v8:8714
> Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61812}
TBR: jgruber@chromium.org
Bug: v8:8714
Change-Id: If7613f6e5f37c5e0d649e8192195594bc6c32100
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627977
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61827}
New spec changes allow anyref tables to be initialized with function
references.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I59596e1e383408114b974fa10529ae15b8cf7a15
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627348
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61823}
This reverts commit 2b0ac2fb9f.
Reason for revert: Breaks scrollingcoordinator/non-fast-scrollable-region-nested.html layout test on https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064/32241
Original change's description:
> [array] Move Array#sort pre-processing to Torque
>
> This CL removes the "PrepareElementsForSort" runtime function, and
> replaces it with a simpler version in Torque. The biggest difference
> is that certain sparse configurations no longer have a fast-path.
>
> The Torque pre-processing step replaces the existing Torque mechanism that
> copied already pre-processed elements into the "work" FixedArray. The Torque
> compacting works as follows:
> - Iterate all elements from 0 to {length}
> - If the element is the hole: Do nothing.
> - If the element is "undefined": Increment undefined counter.
> - In all other cases, push the element into the "work" FixedArray.
>
> Then the "work" FixedArray is sorted as before. Writing the elements from
> the "work" array back into the receiver, after sorting, has three steps:
> 1. Copy the sorted elements from the "work" FixedArray to the receiver.
> 2. Add previously counted number of "undefined" to the receiver.
> 3. Depending on the backing store either delete properties or
> set them to the Hole up to {length}.
>
> Bug: v8:8714
> Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61812}
TBR=peter.wm.wong@gmail.com,jgruber@chromium.org,tebbi@chromium.org,szuend@chromium.org
Change-Id: If1c1bc07f38dfbd4bf6b6ce8f9d70714e7526877
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8714
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627976
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61814}
This CL removes the "PrepareElementsForSort" runtime function, and
replaces it with a simpler version in Torque. The biggest difference
is that certain sparse configurations no longer have a fast-path.
The Torque pre-processing step replaces the existing Torque mechanism that
copied already pre-processed elements into the "work" FixedArray. The Torque
compacting works as follows:
- Iterate all elements from 0 to {length}
- If the element is the hole: Do nothing.
- If the element is "undefined": Increment undefined counter.
- In all other cases, push the element into the "work" FixedArray.
Then the "work" FixedArray is sorted as before. Writing the elements from
the "work" array back into the receiver, after sorting, has three steps:
1. Copy the sorted elements from the "work" FixedArray to the receiver.
2. Add previously counted number of "undefined" to the receiver.
3. Depending on the backing store either delete properties or
set them to the Hole up to {length}.
Bug: v8:8714
Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61812}
Unfortunately, we still have to keep the field because GC mole and Torque
do not support platform specific padding well
(see http://crbug.com/v8/9287).
Bug: v8:9183
Change-Id: I2210be4b8174c97bc82145605f9b862aac3bdc37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624791
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61802}
Adds const information to store field accesses and uses it in load elimination
Change-Id: I00765c854c95c955dabd78557463267b95f75eef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611543
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Schmid <gsps@google.com>
Cr-Commit-Position: refs/heads/master@{#61796}
The indirect function table only exists for table 0 at the moment.
Therefore we should initialize it only for table 0.
R=mstarzinger@chromium.org
Bug: chromium:964607
Change-Id: I88a3a5cb5ebec7f0456adc2cebdf5cc499b22761
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624804
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61794}
This makes the WebAssembly function constructor return a proper function
object. Note that the returned object is not yet callable, only the
prototype structure is in place.
R=jkummerow@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: If6a3d0ae7078b5526606eef1b8fd4815353b850b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627343
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61792}
The tests need to properly hold on to the original fast-mode map,
otherwise the GC might clear that, and so the NormalizedMapCache
lookup would fail due to that.
Bug: chromium:963411, v8:9114, v8:9183, v8:9267
Change-Id: Ic41ed363959a5c182c74097767dc14c366076e17
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627333
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61772}
These instructions were renamed in the October 2, WebAssembly CG meeting. The
issue describing the change is here:
https://github.com/WebAssembly/spec/issues/884
Change-Id: Ia9e8733156b5ed5db7fc9ab1681c1a51b874dd71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1620681
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61711}
This was already unsupported by the map updated because the condition was
manually checked before CanBeInPlaceChangedTo. Since the latter function missed
the check, however, new code using the function (json parser) missed the
relevant check. Simply move the condition to the function.
Bug: chromium:964869
Change-Id: I9424a5706c5f6d637acbf532707da3f1e7d9b55e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1622114
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61703}
This was supposed to be only a clean-up, but the original code even
invalidated a test and thereby covered a test. I fixed the bug here as
well.
Without testing it I think this fixes https://crbug.com/964607.
Bug: v8:9183
Change-Id: I076f40a2302bfd5b7cecd2ae35d4e05a465e054b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621935
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61691}
This CL fixes an issue where V8 does not satisfy the WebAssembly spec of
the anyref proposal.
The table.fill instruction has 3 parameters, {start_index}, {length},
and {value}. V8 trapped with table-out-of-bounds when
{start_index >= table_size}. However, the spec requires that
{start_index == table_size} is valid when {length == 0}.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I5f83a03fb8e349b48c887535f6f065492feb9ac2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609537
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61689}
This is just for convenience, and actually surprising behavior.
R=clemensh@chromium.org
Bug: v8:9183
Change-Id: I3316856e63b97bfb06da897c6f8b716bc988aa36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621932
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61684}
This is a reland of 3dd5661204
The reland introduces a new flag "--experimental-stack-trace-frames".
The flag is disabled by default, but enabled for relevant tests.
The flag stays disabled by default until API frames are eagerly
symbolized to prevent leaks in blink web tests.
Original change's description:
> [stack-trace] Include API functions in Error.stack stack trace
>
> This CL extends Error.stack to include frames of functions declared
> with the C++ FunctionTemplate API. For example, "print" in d8.
>
> Two changes are necessary:
> - HandleApiCall and friends need to go through an BUILTIN_EXIT frame
> instead of an EXIT frame. The existing stack-trace machinery will
> then pick up FunctionTemplate frames without additional changes.
> - Turbofan doesn't go through HandleApiCall, but instead uses an
> ASM builtin to enter FunctionTemplate functions. A "marker"
> frame state is needed to include these frames in the stack trace.
>
> Note: This CL only includes these frames in Error.stack,
> but not (yet) in the stack-trace API (v8.h).
>
> Bug: v8:8742,v8:6802
> Change-Id: Ic0631af883cf56e0d0122a2e0c54e36fed324d91
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609835
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61602}
Bug: v8:8742, v8:6802
Change-Id: I1d3b79cdf0b2edcbaeff1ec15e10deeca725f017
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621925
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61683}
This parameter was just for convenience but did not end up in the
generated bytes.
R=clemensh@chromium.org
Bug: v8:9183
Change-Id: Id4faf5b9ad20a357c069c3189db6ed14945dea8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621929
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61681}
When reconfigure data field (e.g. change representation), it was allowed to transition from dictionary elements kind to sealed elements kind. With this change, this transition is forbidden.
Bug: chromium:963346
Change-Id: I6c9a5f6f269bc5ee4cd6176ff5e8d803f08dba1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613840
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61670}
This adds proper loading and parsing of the arguments that are being
passed to the {WebAssembly.Function} constructor function, including
tests covering most of the negative cases.
R=jkummerow@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Id4d67789604ee72aec5ad831004a01434c1c6d6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619748
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61659}
The invariant is that Map::bit_field2 shouldn't change, and the
IsInRetainedMapListBit apparently changes when the map is held
weakly from optimized code. This causes TurboFan compilations to
change the Map::Hash() result, which in turn causes lookups on
the normalized map cache to miss (and maybe other bad consequences).
With this change we swap Map::IsInRetainedMapListBit (previously in
bit_field2) and Map::HasHiddenPrototypeBit (previously in bit_field3)
to address this problem.
Bug: chromium:963411, v8:9114, v8:9267
Change-Id: I040a27c37305fa602649750bd93bee40c91fca78
Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619747
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61657}
This reverts commit 3dd5661204.
Reason for revert: causes leak tests in blink layout tests to fail: https://ci.chromium.org/p/chromium/builders/ci/WebKit%20Linux%20Trusty%20Leak/34295
Steps to reproduce:
- Build blink_tests with following GN args
is_component_build = false
is_debug = false
strip_absolute_paths_from_debug_symbols = true
- Run
third_party/blink/tools/run_web_tests.py --additional-expectations third_party/blink/web_tests/LeakExpectations --time-out-ms 48000 --enable-leak-detection external/wpt/wasm/webapi/body.any.html
Original change's description:
> [stack-trace] Include API functions in Error.stack stack trace
>
> This CL extends Error.stack to include frames of functions declared
> with the C++ FunctionTemplate API. For example, "print" in d8.
>
> Two changes are necessary:
> - HandleApiCall and friends need to go through an BUILTIN_EXIT frame
> instead of an EXIT frame. The existing stack-trace machinery will
> then pick up FunctionTemplate frames without additional changes.
> - Turbofan doesn't go through HandleApiCall, but instead uses an
> ASM builtin to enter FunctionTemplate functions. A "marker"
> frame state is needed to include these frames in the stack trace.
>
> Note: This CL only includes these frames in Error.stack,
> but not (yet) in the stack-trace API (v8.h).
>
> Bug: v8:8742,v8:6802
> Change-Id: Ic0631af883cf56e0d0122a2e0c54e36fed324d91
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609835
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61602}
TBR=yangguo@chromium.org,sigurds@chromium.org,jgruber@chromium.org,bmeurer@chromium.org,szuend@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8742, v8:6802
Change-Id: I4942cd32c6ee5e249dae046eea6b9b2f7120b8ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617933
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61639}
This is a reland of e7e512da66
Original change's description:
> [turbofan] Add fast path for single-character String#startsWith()
>
> This CL adds a fast path to String#startsWith(s) if s is a
> single character string.
>
> Bug: v8:8400
> Change-Id: Ibd6a9d1e46d98f41c198d2b579208e25003eedb0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1525362
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61504}
Bug: v8:8400
Change-Id: Ic2d60ccb8fdeb51373fcd025a7e970fda0c14d79
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1618342
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61637}
deopt-unlinked.js: bytecode flushing destroys the information that
%GetDeoptCount relies on, so turn that off for this test.
cleanupsome-after-unregister.js: the function-local object {o} is
assumed to be alive throughout the function, so make sure its live
range (from the optimizing compiler's view) extends that far.
Drive-by cleanup: drop some unnecessary casting boilerplate from
Genesis::InitializeGlobal_harmony_intl_date_format_range().
Change-Id: I28617f842fe046dd0875a9a082cfc55a3a076bcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617674
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61621}
es6/classes is slow to run in stress mode and times out on PPC.
As a long term fix we should split this into multiple tests so
each individual test runs faster.
Bug: v8:9246
Change-Id: I95eed06d85f73cc66229dfbd83ac7521dcbbb54f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1615252
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61619}
Fastpath failed to store the hole on the array left side.
Bug: chromium:940274
Change-Id: I1eca7b241030474cf5aed6c68f155a1d22ae553e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617255
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61618}
This adds a constructor function to be used as the base class for all
exported functions. With type reflection enabled exported functions are
instances of this new constructor. Using the constructor directly as
well as the 'type' property is still missing.
R=jkummerow@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Id58359cf7866d24be0745abf36a839d3d86e5922
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617253
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61614}
Skipping rather than reverting the CL that introduced the slowness, due to
the fact that said CL is a Stable blocker fix.
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:9256
Change-Id: I8f8b57c415d2b54fe57c43a87e42990909295c57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1615260
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61603}
This CL extends Error.stack to include frames of functions declared
with the C++ FunctionTemplate API. For example, "print" in d8.
Two changes are necessary:
- HandleApiCall and friends need to go through an BUILTIN_EXIT frame
instead of an EXIT frame. The existing stack-trace machinery will
then pick up FunctionTemplate frames without additional changes.
- Turbofan doesn't go through HandleApiCall, but instead uses an
ASM builtin to enter FunctionTemplate functions. A "marker"
frame state is needed to include these frames in the stack trace.
Note: This CL only includes these frames in Error.stack,
but not (yet) in the stack-trace API (v8.h).
Bug: v8:8742,v8:6802
Change-Id: Ic0631af883cf56e0d0122a2e0c54e36fed324d91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609835
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61602}
Prior to this CL, call counts at function scope were taken from the
FeedbackVector::invocation_count field. This had two major drawbacks:
1. for generator functions, these count the number of resumptions
instead of the number of calls; and 2. the invocation count is not
maintained in optimized code.
The solution implemented here is to add a dedicated call counter at
function scope which is incremented exactly once each time the
function is called.
A minor complication is that our coverage output format expects
function-scope counts in the dedicated CoverageFunction object, and
not as a CoverageBlock. Thus function-scope block counts are initially
marked with magic positions, and later recognized and rewritten during
processing.
This CL thus fixes reported generator function call counts and enables
optimizations in block coverage modes (more to come in a follow-up).
Drive-by: Don't report functions with empty source ranges.
Bug: v8:6000,v8:9148,v8:9212
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: Idbe5edb35a595cf12b6649314738ac00efd173b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613996
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61574}
This avoids the need to throw range errors when we run out of stack, limiting
us only by available memory.
The main parser loop is implemented by two subloops.
The first subloop finishes whenever it generates primitive values, empty
arrays, or empty objects. If a non-empty object or array is started, the loop
continues to parse its first member.
The second subloop consumes produced values and either adds them to the parent
array or object, or returns it. The second loop finishes whenever a next value
needs to be produced. When the loop itself produces a finished array or object,
the loop continues.
Exceptions are handled by moving the cursor to end-of-input. Upon end-of-input,
the first loop sets the continuation to "kFail". That causes the second loop to
tear down continuation stack and related handle scopes, resulting in an empty
handle.
The CL additionally buffers all named properties and elements so we can
immediately allocate a correctly shaped object. For object elements we'll take
flat array or dictionary encoding depending on what is more efficient.
This means that element handles are now allocated in their parent HandleScope,
rather than having local handlescopes per-property (of big objects); which is
why I've adjusted the handle-count test to not allocate as many properties. In
the future it would be nice to not have to allocate (as many) handles since
almost everything in the JSON graph will survive JSON parsing...
Bug: chromium:710383
Change-Id: Ia3a7fd0ac260fb1c0e5f929276792b2f8e5fc0ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609802
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61533}
Tests that expect type feedback vector ensure it by using
%EnsureFeedbackVector intrinsic. These tests now work with lazy feedback
allocation as well. Hence it is no longer required to initialize the
shared function info with a special bailout id.
Bug: v8:8394
Change-Id: Iba2f94be7e5651b4faeb8b3bf604d17fb4b146ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609542
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61509}
This CL adds a fast path to String#startsWith(s) if s is a
single character string.
Bug: v8:8400
Change-Id: Ibd6a9d1e46d98f41c198d2b579208e25003eedb0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1525362
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61504}
Previously we had a special, unshared map on the native context that was
used for results of builtin iterators, which was different from the map
that is created from an object literal like `{value, done}`. This not
only leads to unnecessary polymorphism, but also makes it impossible
for user defined iterators to take the fast-paths that we have in
various places (i.e. in collections or promises).
With this change we now properly share the map for `{value, done}` and
use that for the builtin iterator result objects, as well as the
fast-paths.
Drive-by-fix: Remove the restrictions on map caching and transition
caching during bootstrapping. This no longer makes sense.
Bug: v8:9114, v8:9243
Change-Id: I19eb9071f7ec0ed58f8a6f87eed781bc790174b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609794
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61488}
When using the fast-properties optimization for `delete` with constant
fields we don't properly invalidate the constness on the original map
and might thereby just follow the same transition again later with the
same object, effectively violating the constness of that field. This
disables the fast-properties optimization for `delete` in case of a
field marked as "const" as a quick-fix. We might still want to change
the logic to properly invalidate the "const" bit later.
Bug: chromium:962588, v8:9233
Change-Id: I1d0a8649d117731a0cd5ebdb4b6d0b22a900f33d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609796
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61484}
When receiver is null or undefined we should not look into key. Calling
ToName on key is observable. This cl fixes the GenericKeyedLoadIC to
miss into runtime when the receiver is null or undefined.
Bug: v8:8394
Change-Id: Iaed07cd1b77b63e550284108777e165141af57a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605948
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61481}
