This CL implements the nullish operator in bytecode as defined by:
https://github.com/tc39/proposal-nullish-coalescing. It can be
enabled by passing '--harmony-nullish'.
Nullish is similar to logical operators, but instead of truthy/falsey
values, it short circuits when it evaluates a null or undefined value.
Bug: v8:9547
Change-Id: Ia0f55877fc2714482b5547942baef9733537d1b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738568
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63317}
This CL consists of several preparatory steps for slices in Torque. Above all, it introduces a user-defined struct, torque_internal::Slice<T>, that performs bounds checking and returns references to elements in arrays. To enable this, several smaller changes were also made:
- Constructors of internal classes such as torque_internal::Reference<T> now require a special 'Unsafe' argument, making it clear that there be dragons.
- Struct methods are now declared during finalization. This allows instances of generic structs to have methods referring to the same struct. Previously, methods would be declared before the instance had been fully registered, leading to errors during type resolution. Furthermore, such methods were declared in a temporary namespace, that would then erroneously escape and lead to use-after-free issues.
- Instances of TypeArgumentInference were not running in the correct (Torque) scopes, leading to type resolution errors.
- The chain of ContextualVariable::Scope for any given ContextualVariable (such as CurrentScope) can now be walked, simplifying debugging.
R=jgruber@chromium.org, tebbi@chromium.org
Bug: v8:7793
Change-Id: I36f808f63cc3ce441062dfc56f511f24f1e3121e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758322
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63314}
The linkage should not have any knowledge about the existance of nodes.
R=mstarzinger@chromium.org
Bug: v8:9396
Change-Id: If10bf113c6ec19c434573a8d9bb7b736caef5dee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763532
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63313}
This adds type reflection support to the {WebAssembly.Module.exports} as
well as {WebAssembly.Module.imports} method. It also refactors existing
reflective code to use the internal instead of the public embedder API,
which is slightly more efficient anyways.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I88a6c7e9236a549808707c72e40a63302b7747a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763527
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63312}
This just adds a test case checking against the current behavior, but
expectations might change once the proposal is clarified. For details
see: https://github.com/WebAssembly/js-types/issues/11R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I2fc502460c0a8094a414d138703b75497b2d1c6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762517
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63311}
This CL fixes a bug where function proxies were reported as functions
instead as proxies to devtools, which caused dev-tools to call methods
on the function, possibly triggering side-effects.
Change-Id: I1d5d234b784601bd4b7ec91107e4b0cf0d877d07
Bug: chromium:995753
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762303
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63307}
The tests were assuming that the destructor leaves behind memory in a
defined state when the object was allocated with placement new. Turns
out gcc with no component builds optimizes away the resetting of the
memory.
There's a simpler way to test the functionality by inspecting global
handle counts.
Bug: v8:9639, chromium:995684
Change-Id: I253d84910414c62ca314507b20d2c819f925ea6e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762512
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63303}
When regexp match indices are enabled, we stash required data in the JSRegExpResult object,
and then build a JSRegExpResultIndices object lazily when the 'indices' property is
accessed.
This cl simply checks that fast and slow paths produce the same values for
result.indices and result.indices.groups.
Change-Id: I6322d8eaef4c6e5a0ed3a5aef8b2ff05ac2b2c7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763249
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63301}
This set of macros was only used for one test, while another versions
exists in the header file that's used in the rest of the tests. Clean up
the duplication.
R=ahaas@chromium.org, titzer@chromium.org
Change-Id: I851c47a0748b5c78d9a966dfb59b95a3381e7cf7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1747179
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63300}
This adds type reflection support to the {WebAssembly.Module.exports} as
well as {WebAssembly.Module.imports} method. It also refactors existing
reflective code to use the internal instead of the public embedder API,
which is slightly more efficient anyways.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Ic51b7b4744f7b3ad056a778aecfc4614ca8d6e75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762019
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63299}
private name was not found in the current scope. Outer private names
were sometimes coincidentally correctly resolved if the innermost
ClassScope does not need to allocate a context and does not have a
ScopeInfo.
ClassScope: :LookupPrivateName was not walking the scope chain when a
Change-Id: I18937e6cdf2ad4ae15825b11762fbec7a1358145
Bug: v8:9635
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1761547
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63295}
Since the mutability of HeapNumbers is determined by their owning
object's descriptor array, we can remove the MutableHeapNumber type
entirely, at the cost of a few fewer DCHECKs and a couple of TODOs
to use the descriptor array information.
This is a necessary step towards a follow-up which allows in-place
Double -> Tagged transitions
Design doc: https://docs.google.com/document/d/1VeKIskAakxQFnUBNkhBmVswgR7Vk6T1kAyKRLhqerb4/
Bug: v8:9606
Change-Id: I13209f9c86f1f204088f6fd80089e17d956b4a50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743972
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63294}
Previously, without support for converting strings to numbers we'd
switch to megamorphic state and go to the runtime always to do the
conversion causing a performance cliff.
This patch improves the following js-perf-test scores:
Object-Lookup-String-Constant-BytecodeHandler: 4.25%
Object-Lookup-Index-String-BytecodeHandler: 5.41%
Bug: v8:9449
Change-Id: I63787fa84373fc946f1304b0141e48a52a1b4bcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690953
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63293}
TracedGlobal is already cleared by V8 during garbage collections. It's
the embedders responsibility to clear the reference if it destroys the
underlying reference through other means.
Allow embedders to specify whether they want TracedGlobal to execute
clear on destruction via TracedGlobalTrait.
Bug: chromium:995684
Change-Id: Ieb10cf21f95eb97e01eff15d4fbd83538f17cf7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762007
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63289}
When deserializing from a code snapshot with logging enabled (e.g. when
profiling) then this ensures source positions are collected before
creating code events that need them.
Bug: chromium:994673, v8:9504
Change-Id: Iad7644e983d3004c4889615cf2104dc4ef40da46
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762023
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63286}
This patch implements the declaration of private accessors.
When iterating over the class properties, we track private
accessors associated with the same name in a ZoneHashMap.
Once we get to all the necessary components for a private name
(we know statically whether we should expect only a setter,
only a getter, or both), we emit a call to a runtime function
`CreatePrivateAccessors` that creates an AccessorPair, and
store the components in it. The AccessorPair is then associated
with the private name variable and stored in the context
for later retrieval when the private accessors are accessed.
Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
Bug: v8:8330
Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63284}
Fixes bytecode mismatch between lazy and non-lazy where "this" was
marked as maybe assigned in constructors that called the super
constructor. Since this will return the hole in cases where it was not
yet initialized by super (and the hole is explicitly handled by
JSContextSpecialization::ReduceJSLoadContext), it's safe to treat it as
a constant in all cases. In the case of lazy compilation case, "this"
is never added to the ScopeInfo so is never seen as mutable.
Bug: chromium:994719
Change-Id: I43478fbc626b19eb1533aa9dec61b7f276ae140b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762025
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63283}
Do not pass it as argument to CreateObjectFillerAt and remove the enum.
Bug: v8:9454
Change-Id: Iafa37acbfea73d3cabb1732dbec0944db859fac2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762017
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63282}
Before dd6f4d4f4c, this function was reading a single u8 and verifying
that it was 0x00. The referenced commit dropped this check as part of
implementing decoding for table.get, but neglected to change the read type
to u32v, which is the specified type of this immediate. Fix that.
R=ahaas@chromium.org, titzer@chromium.org
Change-Id: Ic2ce795023ec57be2c95aa79e62d3ccd1aa9c43c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1747178
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63281}
This just adds the upstream tests; our implementation already had support.
Change-Id: If8d340ebe79eae65d12164a01883482d521b8451
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762287
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63280}
This adds type reflection support to the {WebAssembly.Module.exports} as
well as {WebAssembly.Module.imports} method. It also refactors existing
reflective code to use the internal instead of the public embedder API,
which is slightly more efficient anyways.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I168741d382373ec47ebe0517ce7803732cbb3b24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762011
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63276}
This adds type reflection support to the {WebAssembly.Module.exports} as
well as {WebAssembly.Module.imports} method. It also refactors existing
reflective code to use the internal instead of the public embedder API,
which is slightly more efficient anyways.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I5f20ea57261f6433b8d86f55054216bf96b41382
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760826
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63273}
Implements match indices for regexp, as specified by
https://github.com/tc39/proposal-regexp-match-indices,
a stage 3 TC39 proposal. This implementation is hidden
behind the '--harmony-regexp-match-indices' flag.
Regexp match indices extends the JSRegExpResult object
with an array of indices of matches, as well as a
dictionary of capture names to match indices.
Bug: v8:9548
Change-Id: I9866a2d1f5af6a507de710357cb5e74c694e7558
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1734937
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63272}
This brings the graph builder in sync with the serializer (and
exponentiation in sync with the other binary operators).
Bug: chromium:995430, v8:7790
Change-Id: I809b6f3756f75392cdc6747f8bcee8cdf0ee0f74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762013
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63269}
... by making the operator have a control output, since we could deopt
after my last change.
Bug: chromium:995562, v8:7790
Change-Id: Ibc8c44708b4d43c4b2c3dfab2fd8fdf79c7ea671
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762010
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63268}
This change is very mechanical:
own<Foo*> → own<Foo>
vec<Foo*> → ownvec<Foo>
As usual, everything in third_party/ is straight-up copied from upstream.
Change-Id: If5fabda99e2b281da6f2e71ce23a2f5b68aaac86
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760815
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63263}
Adds support to the CPU profiler for scraping the incumbent contexts of
V8 stack frames. While it is generally unsafe to access heap objects
during a profiling interrupt, the native context is uniquely usable due
to being guaranteed an alive root on the stack, as well as its slots
being immutable after context creation.
Change-Id: I2c3149c1302b74d2f13aa99d1fdd0cf006e0f9d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1580020
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63258}
This reverts commit 60843b426b.
Reason for revert: TSAN detected issue between Scavenge workers.
One task could invoke RefillFreeList(), while the other task iterates the remembered set of a swept page.
Original change's description:
> Use list of invalidated objects for old-to-new refs
>
> Instead of inserting "deletion" entries into the store buffer, keep a
> list of invalidated objects to filter out invalid old-to-new slots.
>
> The first CL https://crrev.com/c/1704109 got reverted because both the
> sweeper and the main task were modifying the invalidated slots data
> structure concurrently. This CL changes this, such that the sweeper
> only modifies the invalidated slots during the final atomic pause when
> the main thread is not running. The sweeper does not need to clean this
> data structure after the pause, since the "update pointers" phase
> already removed all invalidated slots.
>
> The second CL https://crrev.com/c/1733081 got reverted because the
> sweeper might find more free space than the full GC before it. If an
> object shrinks after the pause but before the sweep, the invalidated
> object might span free memory and potentially new allocated objects.
> Therefore shrink invalidated objects when processing swept pages on
> the main thread. Also clean recorded slots in the gap.
>
> TBR=petermarshall@chromium.org
>
> Bug: v8:9454
> Change-Id: I80d1fa3bbc24e97f7c97a373aaad66f105456f12
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751795
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63239}
TBR=ulan@chromium.org,hpayer@chromium.org,dinfuehr@chromium.org
Change-Id: I9c6a371ebe36a1873acbe0d6c6a75dd2f5a55f4e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9454
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760817
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63253}
The optional chaining bytecode in delete expressions was
unconditionally jumping if the receiver was nullish, instead
of just when the property was an actual optional chain link.
This change adds the missing check around the jump.
Change-Id: Ic7bed58be4ae62d157e63e4f77666b1abd1f802d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1755264
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63251}
This is a reland of 82111e2286
Relanding since we now have more shards:
https://chromium-review.googlesource.com/c/v8/v8/+/1760810
Original change's description:
> [CSA][cleanup] TNodify some methods related to prototype and property lookup
>
> This is a CL in a string of CLs that aims to TNodify CSA. In particular,
> there were some loads that were done in AnyTagged instead of
> TaggedPointer. TNode-ifying them brings improvement in pointer
> compression since we are able to decompress using the Pointer
> decompression.
>
> TNodified:
> * LoadJSFunctionPrototype
> * TryPrototypeChainLookup
> * OrdinaryHasInstance
>
> Also TNodified loads regarding:
> * FeedbackCell::kValueOffset
> * HeapObject::kMapOffset
> * JSFunction::kSharedFunctionInfoOffset
> * JSFunction::kFeedbackCellOffset
> * Map::kInstanceTypeOffset
> * Map::kInstanceDescriptorsOffset
> * Map::kPrototypeOffset
>
> Drive-by cleanup: StoreJSArrayLength and StoreElements were unused.
>
> Bug: v8:6949, v8:9396
> Change-Id: I89697b5c02490906be1eee63cf3d9e60a1094d48
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1755844
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63216}
Bug: v8:6949, v8:9396
Change-Id: I040aefcf8af60611f7b3c24f3bd5c661e03b6ada
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760811
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63249}
Test mjsunit/regress/regress-992389 explicitly sets the jitless flag
when run.
Skip this test when run on builds without embedded-builtins.
Bug: v8:9632, chromium:992389
Change-Id: Ieb52a33006b1104080d8f5adb8c4f2c36e4413af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758317
Commit-Queue: Patrick Thier <pthier@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63240}
Instead of inserting "deletion" entries into the store buffer, keep a
list of invalidated objects to filter out invalid old-to-new slots.
The first CL https://crrev.com/c/1704109 got reverted because both the
sweeper and the main task were modifying the invalidated slots data
structure concurrently. This CL changes this, such that the sweeper
only modifies the invalidated slots during the final atomic pause when
the main thread is not running. The sweeper does not need to clean this
data structure after the pause, since the "update pointers" phase
already removed all invalidated slots.
The second CL https://crrev.com/c/1733081 got reverted because the
sweeper might find more free space than the full GC before it. If an
object shrinks after the pause but before the sweep, the invalidated
object might span free memory and potentially new allocated objects.
Therefore shrink invalidated objects when processing swept pages on
the main thread. Also clean recorded slots in the gap.
TBR=petermarshall@chromium.org
Bug: v8:9454
Change-Id: I80d1fa3bbc24e97f7c97a373aaad66f105456f12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751795
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63239}
This reverts commit 82111e2286.
Reason for revert: Speculative revert, could be causing timeouts - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20debug/17567
Original change's description:
> [CSA][cleanup] TNodify some methods related to prototype and property lookup
>
> This is a CL in a string of CLs that aims to TNodify CSA. In particular,
> there were some loads that were done in AnyTagged instead of
> TaggedPointer. TNode-ifying them brings improvement in pointer
> compression since we are able to decompress using the Pointer
> decompression.
>
> TNodified:
> * LoadJSFunctionPrototype
> * TryPrototypeChainLookup
> * OrdinaryHasInstance
>
> Also TNodified loads regarding:
> * FeedbackCell::kValueOffset
> * HeapObject::kMapOffset
> * JSFunction::kSharedFunctionInfoOffset
> * JSFunction::kFeedbackCellOffset
> * Map::kInstanceTypeOffset
> * Map::kInstanceDescriptorsOffset
> * Map::kPrototypeOffset
>
> Drive-by cleanup: StoreJSArrayLength and StoreElements were unused.
>
> Bug: v8:6949, v8:9396
> Change-Id: I89697b5c02490906be1eee63cf3d9e60a1094d48
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1755844
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63216}
TBR=rmcilroy@chromium.org,solanes@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6949, v8:9396
Change-Id: Ib6ae8fe86a598ed1066894595565e1162cf7dd1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758310
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63233}
- Move undef closer to end of usage
- Move I64x2ExtractWithF64x2 closer to Extract tests, and into ifdef
scope so it runs on arm64 builds
Change-Id: I7138c44097975d02e97f4b2b9bfcddd8eb9735c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1754544
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63227}
This CL adds additional information in PropertyAccessInfos and FieldAccesses about the map that introduced the accessed field. We use this information to prevent load elimination from incorrectly optimizing certain accesses marked const.
Prior to this CL, load elimination simply stored information about eliminatable field accesses based on objects (identified by nodes in the graph) and offsets (i.e., statically known ones). In the presence of const stores and loads this is insufficient, since a single object (in the above sense) may contain distinct *const* properties at the same offset throughout its lifetime. As an example, consider the following piece of code:
let obj = {};
obj.a = 0;
obj[1024] = 1; // An offset of >=1024 forces an elements-kind transition
delete obj.a;
obj.b = 2;
assertEquals(obj.b, 2);
In this scenario, *both* the first ('obj.a = 0') and the second ('obj.b = 2') store to a field will be marked const by the runtime. The reason that storing to 'a' above ends up being marked const, is that 'a' before and after the elements-kind transition is encoded in separate transition trees. Removing 'a' ('delete obj.a') only invalidates const-ness in the dictionary-elements transition tree; not the holey-elements one used at the time of 'obj.a = 0'.
The above situation on its own violates an invariant in load elimination. Namely, we assume that for the same object and offset, we will never encounter two const stores. One can extend the above snippet to coax load-elimination into producing incorrect results. For instance, by "hiding" 'obj.b = 2' in an unoptimized function call, the consecutive load from 'b' will incorrectly produce 0, violating the assert.
R=neis@chromium.org, tebbi@chromium.org
Bug: chromium:980183, chromium:983764
Change-Id: I576a9c7efd416fa9db6daff1f42d483e4bd369b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751346
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@{#63226}
There are some accesses that we know that are pointers, and we can
specialize them to have Pointer as their Machine Type and Write Barrier.
Drive-by fix: ForJSGeneratorObjectParametersAndRegisters can be changed
to use Pointer.
Bug: v8:7703
Change-Id: I88e371746fc5f08c84795c95b1885264ef6c067c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741658
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63223}
This is a CL in a string of CLs that aims to TNodify CSA. In particular,
there were some loads that were done in AnyTagged instead of
TaggedPointer. TNode-ifying them brings improvement in pointer
compression since we are able to decompress using the Pointer
decompression.
TNodified:
* LoadJSFunctionPrototype
* TryPrototypeChainLookup
* OrdinaryHasInstance
Also TNodified loads regarding:
* FeedbackCell::kValueOffset
* HeapObject::kMapOffset
* JSFunction::kSharedFunctionInfoOffset
* JSFunction::kFeedbackCellOffset
* Map::kInstanceTypeOffset
* Map::kInstanceDescriptorsOffset
* Map::kPrototypeOffset
Drive-by cleanup: StoreJSArrayLength and StoreElements were unused.
Bug: v8:6949, v8:9396
Change-Id: I89697b5c02490906be1eee63cf3d9e60a1094d48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1755844
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63216}
Fixes DCHECK failure in DropStackFrameCacheCommon by returning early if
the source_position_table is Exception.
Bug: chromium:990582, v8:8510
Change-Id: I671f3e0cdc9f880dedf8ecd2fffb1083229dc6dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752856
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63209}
This CL increases the maximum number of arguments for CallCFunction to
10 (was 9 previously).
All simulators also support up to 10 arguments now for host-calls.
Bug: v8:9621
Change-Id: Ib21cd39e965cdfcb0b04412261dc02e5fe106e47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752852
Commit-Queue: Patrick Thier <pthier@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63208}
Otherwise there is a mismatch between eager parsing (where the reciever
is marked as MaybeAssigned) and lazy parsing (where the receiver is
deserialized and not marked MaybeAssigned) for arrow functions that
have an inner scope that calls eval.
BUG=chromium:989914
Change-Id: I8b8b78140858985a75a971b0e0a95bd61463457b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752851
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63206}
This is a reland of
https://chromium-review.googlesource.com/c/v8/v8/+/1749712 with a fix in
test-run-wasm-simd.cc to use base::Divide to work around C++ undefined
behavior when the denominator is 0.
Bug: v8:8460
Change-Id: Ia0a4ff621cccc6d9b7528717bf3fa7c79e42ba1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745819
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63198}
When GC triggered while an exception is pending, a read to
memory that was no longer valid could happen while backtracking in the
regexp interpreter (introduced with commit fb0df2c).
This CL prevents this dirty read, that could have been a security issue.
Bug: chromium:992389, v8:9575
Change-Id: Ie1acd6faa16665e211666c6a8dcf2a9d74e0c886
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751342
Commit-Queue: Patrick Thier <pthier@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63195}
When a RelocatingCharacterStream is Seeked, it's buffer_pos_ could be set a non-zero value.
However, UpdateBufferPointers was assuming the position was zero to relocate the buffer_start_
and buffer_end_, which would lead to the stream becoming misaligned. Fix this and add a
unittest and the clusterfuzz script which highlighted the issue.
BUG=chromium:991133
Change-Id: I20dd510b3dcc5df6df058b7e06d2c8a838aef855
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751782
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63190}
This makes sure that the above predicate is independent of any global
process-wide state. The state of enabled features is now passed in
explicitly.
R=thibaudm@chromium.org
Change-Id: I5d44e2b0c0843d2e4f26aaf0d58d23afd5943726
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751348
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63188}
Create canonical ScopeInfos for the global this binding and empty function in
the read only space, rather than creating them during bootstrapping for each
native context. This saves some memory, and also means we don't need to access
the native context to get the global this binding in when deserializing a
scope info, which is important since parsing should be native context independent.
BUG=chromium:992063
Change-Id: I800f576e8e9b95d46e043cba0c1a03ae19a683c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748690
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63174}
Now that all uses of LoadStackPointer have been removed, this CL cleans
up related code:
- Removed LoadStackPointer.
- Removed ArchStackPointer.
- Removed IA32StackCheck.
- Removed X64StackCheck.
- Removed StackCheckMatcher.
All stack checks now follow a simple path without matchers or special
register constraints: they load the limit and pass it to
StackPointerGreaterThan, which is finally handled by code generation.
Bug: v8:9534
Change-Id: Ib1d7be1502a471541d6441f3261aac0c949525fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748737
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63166}
This removes LoadStackPointer and its last remaining use in the
interpreter assembler.
Bug: v8:9534
Change-Id: I19aafb12c5fd50248841a3d92448e64243c723ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748729
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63164}
We assume that during bootstrapping, we won't create script contexts.
This is wrong, since JavaScript code in extensions may introduce
let/const variables.
R=jgruber@chromium.org
Change-Id: I02595abdbb65f41faffc90bde142849bbde6b554
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666994
Auto-Submit: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63161}
This CL implements a naive tiering-up strategy where the interpreter
is used for the first execution for every regex, and the compiler is
used for every execution after that. The only exception is if a
global replace is being executed on a regex, we eagerly tier-up to
native code right away.
To use the tier-up logic --regexp-tier-up needs to be set. It is
currently disabled by default.
Bug v8:9566
Change-Id: Ib64ed77cbfcde10411161c0541dfa2501a0a93bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710661
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ana Pesko <anapesko@google.com>
Cr-Commit-Position: refs/heads/master@{#63150}
This reverts commit d1a4706af9.
Reason for revert: Experiment over.
Original change's description:
> Reland "[ptr-compr][arm64] Temporarily enable pointer compression on arm64"
>
> This is a reland of f5611402f7
>
> Original change's description:
> > [ptr-compr][arm64] Temporarily enable pointer compression on arm64
> >
> > ... and make sure that the arm64 ptr-compr bots proceed testing V8 without
> > pointer compression in order to keep testing the other config.
> >
> > Commented out the 'extra' variant since it was crashing. Opened a bug
> > regarding that: https://bugs.chromium.org/p/v8/issues/detail?id=9568
> >
> > Similar to x64's https://chromium-review.googlesource.com/c/v8/v8/+/1607654
> >
> > Bug: v8:7703
> > Change-Id: Ifd46b029bab34524f9f536dcdbd1574f2ddcbf37
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724216
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63019}
>
> Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel_ng
> Bug: v8:7703
> Change-Id: I1a82b87bf6db4e6d100aeffc29dae60ba73d8119
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730998
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63043}
TBR=machenbach@chromium.org,tmrts@chromium.org,solanes@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7703
Change-Id: I86a801d44ad4ea14b1388ad8ca6109cc8a57a7d7
Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746470
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63148}
This contains the following upstream commits:
486d3fe: Rename DEBUG to WASM_API_DEBUG
8d8e37d: Explicitly number wasm_valkind_t
299ebe0: Fix underlying types for enums
70be7c6: Fix test
Change-Id: I692fb6c909e5211920438740d2c57ea7ee74ab12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745483
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63147}
- Adds regular native heap entries to the HeapObjectsMap.
- Adds a side map for keeping a mapping of native objects to their canonical
heap entry that they have been merged into.
Change-Id: Ida00628126ded1948ceb2a0cbe14da817af7f361
Bug: chromium:988350
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720810
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63140}
This is the first in a series of changes to reduce the number of
bytecodes generated for the iteration protocol based operations.
The GetIterator bytecode introduced in this change currently loads the
@@iterator symbol from an object that was previously done using the
LdaNamedProperty bytecode. This change uses builtin-based mechanism
that would be extended to perform additional operations in the future
on absorbing the bytecodes associated with the GetIterator operation
from the iteration protocol.
Bug: v8:9489
Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63139}
This is a reland of 1152445367
Original change's description:
> [wasm] Test concurrent code emission
>
> This extends the jump table stress test. Currently, we generate
> different thunks (on the main thread) and then concurrently update the
> jump table to jump to one of these thunks.
> With this CL, we also generate the thunks concurrently. So this also
> tests whether there is proper synchronization between code generation
> and executing it in another thread.
>
> R=ahaas@chromium.org, mstarzinger@chromium.org
>
> Bug: v8:9477
> Change-Id: I3598329e37482ebd27a13acc752581c714226184
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735319
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63097}
Bug: v8:9477
Change-Id: Iac696f1ff3cd5209231a8dd8d1500cf77c2777b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1739370
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63138}
Since the same value is also returned in 'result' field it is still populated in accord with 'returnByValue' parameter. This behavior is consistent with 'evaluate'.
R=dgozman@chromium.org, lushnikov@chromium.org
Bug: v8:9509
Change-Id: I9f72682f87492ce5cd0759dce75ab3d75a5fe31c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1707331
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Yury Semikhatsky <yurys@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63134}
This reverts commit e2f98ec22c.
Reason for revert: Caused performance regression in ArrayLiteralInitialSpreadSmallHoley.
Original change's description:
> Use list of invalidated objects for old-to-new refs
>
> Instead of inserting "deletion" entries into the store buffer, keep
> a list of invalidated objects to filter out invalid old-to-new slots.
>
> The first CL https://crrev.com/c/1704109 got reverted because both the sweeper and the main task were modifying the invalidated slots data structure concurrently. This CL changes this, such that the sweeper only modifies the invalidated slots during the final atomic pause when the main thread is not running. The sweeper does not need to clean this data structure after the pause, since the "update pointers" phase already removed all invalidated slots.
>
> Bug: v8:9454
> Change-Id: Iffb5bf96de2c89eee1ee1231a3414a0f2a155cbc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733081
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63087}
TBR=ulan@chromium.org,petermarshall@chromium.org,dinfuehr@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9454
Change-Id: I328b9f72df45fc9570d4a4d1b5389eac010638c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743970
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63131}
Cleans up a plethora of JumpIfUndefined().JumpIfNull()
occurances by introducing a new JumpIfUndefinedOrNull
bytecode.
Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63130}
The spec says we have to insert some wrapper code with extra line breaks
in it, but this confuses users when they see stack traces as the line
numbers come from the code with the wrapper, instead of the original.
This CL sets line_offset on the script to indicate that line numbers
should be offset by the 2 extra line breaks when reading them out e.g.
for the purpose of stack traces.
Bug: chromium:109362
Change-Id: Ib608e1043c38b595b1466766f7592e993ee3b996
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741660
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63127}
With lazy feedback allocation, we don't have feedback vectors when function
starts executing. If we mark the function on the first execution we would
be missing feedback for the initial part of the function and hence the
optimized code will not be useful.
This cl resets the optimization markers on OSR if the invocation count of
the function is less than 1. We may still do wasted optimizations if the
function is hot enough for optimizing but not for OSRing. In the long term
we may want to fix it differently. This fix covers the most common cases
in benchmarks.
Bug: chromium:987523
Change-Id: I1cfe82e6b9f95278b77c99b77d4b981828b5c0ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1739373
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63124}
This CL adds an access check for the arguments to all calls to
{console} like {console.log}. This is needed since the DevTools
protocol notificiation event does not contain the context in which
the {console.log} call occurred. Only the context of the argument.
When DevTools then reads properties for the preview of the argument,
it uses arguments context, instead of the calling context, potentially
leaking objects/exceptions into the calling context.
Bug: chromium:987502, chromium:986393
Change-Id: I6f7682f7bee94a28ac61994bad259bd003511c39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741664
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63122}
Each LHS expression that contains an optional chain of some form is
wrapped in an OptionalChain node. This root node allows us to use a
single jump location for every individual item in the chain,
improving the performance and simplifying the implementation.
Bug: v8:9553
Change-Id: I678563928b2dbfd6200bff55801919d4fd816962
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1723359
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63120}
This reverts commit 79b00555ea.
Reason for revert: needs more discussion
Original change's description:
> [torque] introduce JSAny type for user-accessible JavaScript values
>
> This CL introduces a JSAny type for user-exposed JavaScript values and
> a few new types to define it. Especially, it splits Symbol into
> PrivateSymbol (not exposed) and PublicSymbol (JavaScript exposed
> symbols).
>
> The change is mostly mechanical, but a few things are interesting:
> - PropertyKey and JSPrimitive were designed to coincide with the spec
> notions of IsPropertyKey() and primitive value, respectively.
> - Since Name is an open type, we define AnyName to be the known
> subtypes of Name. This is not too elegant, but by using AnyName
> instead of Name, typeswitch can properly conclude something if a
> subtype of Name is excluded.
>
> Small drive-by changes, which were necessary:
> - Allow subtyping on label parameters.
> - Fix the formatting of typeswitch, it was broken with union types
> in case types.
>
> Bug: v8:7793
> Change-Id: I14b10507f8cf316ad85e048fe8d53d1df5e0bb13
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735322
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63114}
TBR=neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org
Change-Id: Ifde7881d74afe407628f40047997339d54cb2424
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741652
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63115}
This CL introduces a JSAny type for user-exposed JavaScript values and
a few new types to define it. Especially, it splits Symbol into
PrivateSymbol (not exposed) and PublicSymbol (JavaScript exposed
symbols).
The change is mostly mechanical, but a few things are interesting:
- PropertyKey and JSPrimitive were designed to coincide with the spec
notions of IsPropertyKey() and primitive value, respectively.
- Since Name is an open type, we define AnyName to be the known
subtypes of Name. This is not too elegant, but by using AnyName
instead of Name, typeswitch can properly conclude something if a
subtype of Name is excluded.
Small drive-by changes, which were necessary:
- Allow subtyping on label parameters.
- Fix the formatting of typeswitch, it was broken with union types
in case types.
Bug: v8:7793
Change-Id: I14b10507f8cf316ad85e048fe8d53d1df5e0bb13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735322
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63114}
This patch stores the home objects in private methods that
access super properties.
Bug: v8:8330
Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#63113}
Currently, the private name symbols are displayed in the block
scopes in DevTools, though these are just implementation details
of private fields. This patch hides them from the block scope
by marking variables with names starting with `#` as synthetic.
The private fields are still going to show up in the previews
of objects, only the key symbols themselves are going to be hidden.
Bug: v8:8773, chromium:982267
Change-Id: I059472d05c26a1f035ab92718a1b7e5ecafa8dc4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741846
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#63112}
This CL changes {descriptionForError} to not immediately return when a {stack}
is not found, but instead try to lookup and append the {message} as well.
The existing logic to build a description in a specific way when the class
of the exception does not match, is retained for backwards compatibility.
Bug: chromium:954017
Change-Id: I9fa1d2807e2877bd988f82b4b57cf329bcd9f61b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738862
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63111}
Also roll 0705a10: Comments
Change-Id: I9802283fa68093839286779503b6073122cbc8d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1739369
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63108}
Ongoing cleanup to use the same term everywhere.
Bug: chromium:913887
Change-Id: Ifc4d4de0c2dfd9f1150e61d64cf7f91cf923aa24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738865
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63101}
This reverts commit 1152445367.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/27728
Original change's description:
> [wasm] Test concurrent code emission
>
> This extends the jump table stress test. Currently, we generate
> different thunks (on the main thread) and then concurrently update the
> jump table to jump to one of these thunks.
> With this CL, we also generate the thunks concurrently. So this also
> tests whether there is proper synchronization between code generation
> and executing it in another thread.
>
> R=ahaas@chromium.org, mstarzinger@chromium.org
>
> Bug: v8:9477
> Change-Id: I3598329e37482ebd27a13acc752581c714226184
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735319
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63097}
TBR=mstarzinger@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I1c95cb43aa23340913de9cfad9988d0c583cc266
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9477
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1739368
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63100}
This cl makes IsLockFree return true for 8 bytes on x64 platforms.
The standard is unfortunately a bit vague on what exactly 'lock free' means.
As a result, we err on the side of caution. We can revisit this, but first
we need the specification to nail down exactly what 'lock free' in this
context.
Bug: v8:8100
Change-Id: I0a6099c6cb95a5581f3e71d0267857b88b4a2f0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735592
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63099}
This extends the jump table stress test. Currently, we generate
different thunks (on the main thread) and then concurrently update the
jump table to jump to one of these thunks.
With this CL, we also generate the thunks concurrently. So this also
tests whether there is proper synchronization between code generation
and executing it in another thread.
R=ahaas@chromium.org, mstarzinger@chromium.org
Bug: v8:9477
Change-Id: I3598329e37482ebd27a13acc752581c714226184
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735319
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63097}
Instead of inserting "deletion" entries into the store buffer, keep
a list of invalidated objects to filter out invalid old-to-new slots.
The first CL https://crrev.com/c/1704109 got reverted because both the sweeper and the main task were modifying the invalidated slots data structure concurrently. This CL changes this, such that the sweeper only modifies the invalidated slots during the final atomic pause when the main thread is not running. The sweeper does not need to clean this data structure after the pause, since the "update pointers" phase already removed all invalidated slots.
Bug: v8:9454
Change-Id: Iffb5bf96de2c89eee1ee1231a3414a0f2a155cbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733081
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63087}
Update the TracingCpuProfiler test to work properly with perfetto.
Roll perfetto to get fixes for bugs encountered with starting/stopping
tracing rapidly, which happens in the test for the tracing profiler.
Add a check that the DataSource::Register call was successful to flush
out any errors there (although they are fixed by the perfetto roll).
Emit a fake trace event when stopping tracing in order to avoid
losing the final trace event that the user provided. Remove the ad-hoc
fake final trace events that the cctests for perfetto added.
Add a test StartAndStopRepeated which flushes out the issues fixed by
the perfetto roll.
TBR=yangguo@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng
Bug: v8:8339
Change-Id: I042d7385486bf42c86f1631406974693868a477f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731006
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63083}
This is a reland of 159df2488c
Original change's description:
> [ic] Don't transition to premonomorphic state
>
> We used to use premonomorphic state to delay initializing the ICs.
> This optimization was to avoid the cost of setting up handlers if the
> code executed only once. With lazy feedback allocation we no longer
> need this.
>
> This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and
> StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to
> runtime in the uninitialized state and use the builtin when there
> is no feedback.
>
>
> Change-Id: I1633e61ea74664da51348e362c34c47a017a264a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63020}
Change-Id: Ica7eb65649615c2f8410d5b815a98b55cb1cfc4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731000
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63082}
This reverts commit 5611f70b3d.
Reason for revert: flaky tests: v8:9588, v8:9587
Original change's description:
> "Reland x4 [arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of bc33f5aeba
>
> Contributed by titzer@chromium.org
>
> 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.
>
> TBR=yangguo@chromium.org
>
> BUG=v8:9380,v8:9221,chromium:986318
>
> Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63041}
TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,clemensh@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9380, v8:9221, chromium:986318
Change-Id: Ic7381239f4e90d0c437b7e47a5ac6e8bce60f882
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1736747
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63081}
Now that we can short-circuit control flow in the optimizing compiler,
there is no more need for BranchIf... macros in CSA/Torque.
Thus removing support for them in Torque and rewriting Torque macros to
use bool return values instead.
Bug: v8:7793
Change-Id: Ie4b7522aa5558be038fe821d8b5d02859d522ed1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724211
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63079}
This CL changes the signature of AccessorPair::GetComponent to take
an additional parameter {native_context}. The current native_context
does not always match the native context of the holder, resulting in
JSFunctions that have the wrong native context for lazy instantiated
AccessorPairs.
Bug: chromium:989909, v8:6495
Change-Id: I45bfcb27ac367858dd6788736eba1a2e1302e802
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735311
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63078}
This CL changes the way AccessorPairs are collected for instantiation
when debug break trampolines are installed.
Instead of walking the heap and looking at AccessorPairs directly, we
look at all JSObjects and collect AccessorPairs via each objects
descriptor array. This way, we can associate the correct native
context with each collected AccessorPair.
The current native context is not always the correct context to instantiate
the getter and setter JSFunctions for an AccessorPair.
Bug: chromium:986063
Change-Id: I124a0802f4938b95f1ad75efc65eb05b66bcfc67
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735310
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63071}
When a fast path was added for Math.hypot, the algorithm was also
simplified. This simplification turns out to be incorrect in some rare
edge cases. This cl reverts back to the original algorithm and converts it to torque.
Original cl: https://chromium-review.googlesource.com/c/v8/v8/+/1684178
Bug: v8:9546
Change-Id: If4e21504732f46081a8de823f50f499917f1a20c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725200
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63070}
Also add a IsExtreme(double) overload.
This wasn't causing issues because there was no codepath
which exercised it (only approx operations did).
Change-Id: If7583fb567137c428d16c0d2cdfc37e086f7f3fd
Bug: v8:8460
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726675
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63053}
For variable proxies in a function inside an eval scope that point to
a dynamic variable in the eval scope, the current scope resolution will
find this variable only when the function is eagerly compiled, as the
eval scope only exists during top-level eval compilation. This causes
a mismatch between lazy- and eager- compiled functions.
With this patch, we skip these dynamic variables during lookup, so that
the lookup for the variable proxy always finds a kDynamicLocal or
kDynamicGlobal, both when compiled lazily and eagerly. This is a minor
pessimisation of performance (as we know that the lookup has to be
dynamic), but unblocks other improvements which require idempotent
bytecode generation (such as lazy source positions).
Note that the alternative, of simply not tracking dynamic variables on
the eval scope at all, is not viable due to needing this information
during conflict detection.
Bug: v8:8510
Bug: v8:9511
Change-Id: Ifa72ec05e9a97b7be418912340081b9656765fd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733077
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63051}
MIPS64 has a user space of 2^40 bytes on most processors, address
space limits needs to be smaller. 256G is ok, but it will cause
many wasm tests get a OOM error.
This patch also skip some tests which need correct IEEE-745 2008
NaN bit patterns on mips.
Change-Id: I52968df3934e8748b2c42a0abf19db1540441d2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1712929
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Yu Yin <xwafish@gmail.com>
Cr-Commit-Position: refs/heads/master@{#63050}
This makes sure the "parameters" and "results" properties of the passed
FunctionType object can be arbitrary iterable objects, not just plain
JavaScript arrays.
R=clemensh@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Icba18c418e549deba9fff1855be4956813b1a953
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733071
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63049}
This CL adds regression tests for two bugs where the wrong native
context is used when lazy accessors are instantiated.
The first bug injects an object created in context 1, into another
context 2. The object has an accessor pair installed via
FunctionTemplate. In context 2, the property descriptor of this
accessor is retrieved, causing the JSFunction to be instantiated
with the current context (context 2) instead of the creation
context of the object (context 1).
The second bug is similar. When breakpoints are set, the whole heap
is walked and all lazy accessor pairs are instantiated. This again
uses the current context instead of using the context from which
a AccessorPair originates.
Bug: chromium:986063, chromium:989909
Change-Id: Iaaea6e81f1b9f6b55fc7583b260aa9aea035a8d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730999
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63048}
It's too slow and flakes on "V8 Linux - full debug"
Change-Id: I2a83a7a2de6a3865d230edb847a658b1b8b23bec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733076
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63047}
This is a reland of f5611402f7
Original change's description:
> [ptr-compr][arm64] Temporarily enable pointer compression on arm64
>
> ... and make sure that the arm64 ptr-compr bots proceed testing V8 without
> pointer compression in order to keep testing the other config.
>
> Commented out the 'extra' variant since it was crashing. Opened a bug
> regarding that: https://bugs.chromium.org/p/v8/issues/detail?id=9568
>
> Similar to x64's https://chromium-review.googlesource.com/c/v8/v8/+/1607654
>
> Bug: v8:7703
> Change-Id: Ifd46b029bab34524f9f536dcdbd1574f2ddcbf37
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724216
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63019}
Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel_ng
Bug: v8:7703
Change-Id: I1a82b87bf6db4e6d100aeffc29dae60ba73d8119
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730998
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63043}
This is a reland of bc33f5aeba
Contributed by titzer@chromium.org
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.
TBR=yangguo@chromium.org
BUG=v8:9380,v8:9221,chromium:986318
Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63041}
Previously when creating a new generic struct, one had to explicitly provide all type arguments, e.g., for the generic struct
struct Box<T: type> {
const value: T;
}
one would initialize a new box using
const aSmi: Smi = ...;
const box = Box<Smi> { value: aSmi };
With the additions in this CL the explicit type argument can be omitted. Type inference proceeds analogously to specialization of generic callables.
Additionally, this CL slightly refactors class and struct initialization, and make type inference more permissive in the presence of unsupported type constructors (concretely, union types and function types).
R=jgruber@chromium.org, tebbi@chromium.org
Change-Id: I529be5831a85d317d8caa6cb3a0ce398ad578c86
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728617
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63036}
When the flag is on and some of the functions don't have bytecode,
we should gracefully print "no bytecode" instead of crashing.
Bug: chromium:983267
Change-Id: Id4e3385cd871a2dd5bead38c29a41b38319cc8d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731003
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63031}
now that we are shipping this by default, we can remove the flag.
Change-Id: I298691df3eec934a5add1aa2a2748a0f3a884ab6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726452
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63026}
The unittest for {WasmCodeManager} currently disables implicit
allocations for win64 unwind info, but still deals with the implicitly
allocated jump table. With the addition of a far jump table, this logic
would get even more complex.
Thus this CL introduces a testing flag on the {WasmCodeManager} to
disable all implicit allocations, and uses that instead in the
{WasmCodeManagerTest}.
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: I45e4bc6b9fec6d7286bf6b45f778681ae0dba746
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725622
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63025}
This reverts commit 159df2488c.
Reason for revert: Breaks large-classes-properties test (https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906338563361079200/+/steps/Bisect_159df248/0/steps/Retry_-_isolates/0/logs/large-classes-properties/0)
Original change's description:
> [ic] Don't transition to premonomorphic state
>
> We used to use premonomorphic state to delay initializing the ICs.
> This optimization was to avoid the cost of setting up handlers if the
> code executed only once. With lazy feedback allocation we no longer
> need this.
>
> This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and
> StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to
> runtime in the uninitialized state and use the builtin when there
> is no feedback.
>
>
> Change-Id: I1633e61ea74664da51348e362c34c47a017a264a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63020}
TBR=mythria@chromium.org,verwaest@chromium.org
Change-Id: I4fad4e8b881d4a3f8d12149e1797b217a317eaee
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730995
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63023}
This removes the explicit {kCallWithCallerSavedRegisters} opcode which
is just a regular call node with special handling for saving/restoring
caller saved registers before/after the call. This is now handled via
the {CallDescriptor::kCallerSavedRegisters} flag.
R=neis@chromium.org
BUG=v8:9396
Change-Id: Ie6421085eb2be8a067040222cd5215a9b1013048
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728611
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63021}
We used to use premonomorphic state to delay initializing the ICs.
This optimization was to avoid the cost of setting up handlers if the
code executed only once. With lazy feedback allocation we no longer
need this.
This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and
StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to
runtime in the uninitialized state and use the builtin when there
is no feedback.
Change-Id: I1633e61ea74664da51348e362c34c47a017a264a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63020}
... and make sure that the arm64 ptr-compr bots proceed testing V8 without
pointer compression in order to keep testing the other config.
Commented out the 'extra' variant since it was crashing. Opened a bug
regarding that: https://bugs.chromium.org/p/v8/issues/detail?id=9568
Similar to x64's https://chromium-review.googlesource.com/c/v8/v8/+/1607654
Bug: v8:7703
Change-Id: Ifd46b029bab34524f9f536dcdbd1574f2ddcbf37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724216
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63019}
The mask should cover the sign (1 bit), exponent (11 bits) and quiet bit (1 bit) of significand, total of 13 bits. The old mask only covered 9 bits.
Change-Id: I6ec402b4cec34978eac8fa3e5452ad22540a93ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726984
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63015}
This reverts commit df8e617772.
Reason for revert: Multiple flakes in apparently related areas:
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906409837768155568/+/steps/Check__flakes_/0/logs/BackingStoreTest.RacyGrowWasmMem.../0
Original change's description:
> "Reland x3 [arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of bc33f5aeba
>
> 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,chromium:986318
> TBR=ulan@chromium.org
>
> Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63007}
TBR=mstarzinger@chromium.org,titzer@chromium.org,mlippautz@chromium.org
Change-Id: If0266e5893b1325a332d5986337fa7ece2cb6943
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9380, v8:9221, chromium:986318
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1729549
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63011}
This is a reland of 4b15b984ad
Updates since original: fix an arithmetic overflow bug, remove an invalid
DCHECK, add a unit test that would trigger that DCHECK.
Original change's description:
> [regexp] Better quick checks on loop entry nodes
>
> Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
> change is inspired by attempting to exit earlier from generated RegExp
> code, when no further matches are possible because any match would be
> too long. The motivating example this time is the following expression,
> which tests whether a string of Unicode playing cards has five of the
> same suit in a row:
>
> /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
>
> A human reading this expression can readily see that any match requires
> at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
> each repeated option reports its minimum distance to the end of a match
> as zero. This is correct, because the LoopChoiceNode's behavior depends
> on additional state (the loop counter). However, the preceding node, a
> SET_REGISTER action that initializes the loop counter, could confidently
> state that it consumes at least 10 characters. Furthermore, when we try
> to emit a quick check for that action, we could follow only paths from
> the LoopChoiceNode that are possible based on the minimum iteration
> count. This change implements both of those "could"s.
>
> I expect this improvement to apply pretty broadly to expressions that
> use minimum repetition counts and that don't meet the criteria for
> unrolling. In this particular case, I get about 12% improvement on the
> overall UniPoker test, due to reducing the execution time of this
> expression by 85% and the execution time of another similar expression
> that checks for n-of-a-kind by 20%.
>
> Bug: v8:9305
>
> Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62963}
Bug: v8:9305
Change-Id: I992070d383009013881bf778242254c27134b650
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726674
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63009}
This is a reland of 517ab73fd7
Updates since original: now compressed pointers passed to the function
GetObjectProperties are required to be sign-extended. Previously, the
function allowed zero-extended values, but that led to ambiguity on
pointers like 0x88044919: is it compressed or is the heap range actually
centered on 0x100000000?
Original change's description:
> Add postmortem debugging helper library
>
> This change begins to implement the functionality described in
> https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
> for investigating V8 state in crash dumps.
>
> This change adds a new library, v8_debug_helper, for providing platform-
> agnostic assistance with postmortem debugging. This library can be used
> by extensions built for debuggers such as WinDbg or lldb. Its public API
> is described by debug-helper.h; currently the only method it exposes is
> GetObjectProperties, but we'd like to add more functionality over time.
> The API surface is restricted to plain C-style structs and pointers, so
> that it's easy to link from a debugger extension built with a different
> toolchain.
>
> This change also adds a new cctest file to exercise some basic
> interaction with the new library.
>
> The API function GetObjectProperties takes an object pointer (which
> could be compressed, or weak, or a SMI), and returns a string
> description of the object and a list of properties the object contains.
> For now, the list of properties is entirely based on Torque object
> definitions, but we expect to add custom properties in future updates so
> that it can be easier to make sense of complex data structures such as
> dictionaries.
>
> GetObjectProperties does several things that are intended to generate
> somewhat useful results even in cases where memory may be corrupt or
> unavailable:
> - The caller may optionally provide a type string which will be used if
> the memory for the object's Map is inaccessible.
> - All object pointers are compared against the list of known objects
> generated by mkgrokdump. The caller may optionally provide the
> pointers for the first pages of various heap spaces, to avoid spurious
> matches. If those pointers are not provided, then any matches are
> prefixed with "maybe" in the resulting description string, such as
> "maybe UndefinedValue (0x4288000341 <Oddball>)".
>
> Bug: v8:9376
>
> Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62882}
Bug: v8:9376
Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63008}
This is a reland of bc33f5aeba
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,chromium:986318
TBR=ulan@chromium.org
Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63007}
With the arrival of generic structs (https://chromium-review.googlesource.com/c/v8/v8/+/1714868) the existing type inference procedure for generic calls became incomplete, since it could not infer types that were only constrained as part of generic types. For instance, given
struct Box<T: Type> { ... }
macro unbox<T: type>(box: Box<T>): T
the type argument (Smi) at the following call site
const box: Box<Smi> = ...;
unbox(box);
could not be inferred.
This CL re-implements the inference procedure and documents the semantics of type argument inference in Torque a bit more clearly.
R=tebbi@chromium.org
Change-Id: I868f16afbd9864b9c810ac49bc1639b467df939c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720812
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63005}
On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend
doesn't emit unwinding info and also because it doesn't emit ABI compliant
stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and
documented below:
https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0
This problem can be fixed similarly for Windows ARM64 by observing that V8
frames usually all have the same prolog which maintains a chain via frame
pointer (fp or x29 register).
stp fp, lr, [sp, ...]
One exception is JSEntry which stops fp pointer chain and needs to be handled
specially.
So it is possible to define XDATA with UNWIND_CODE which specify how Windows
should walk through V8 dynamic frames. The same as X64, since V8 Code objects
are all allocated in the same code-range for an Isolate, it is possible to
register at most 2 XDATA and a group of PDATA entries to cover stack walking
for all the code generated inside that code-range. This is more than 1
PDATA/XDATA because according to the Windows ARM64 exeption handling document,
1 PDATA can cover less than 1MB code range (see below doc).
https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling
This PR implements stackwalk for Windows ARM64 to be on par with X64, including
embedded builtins, jitted code and wasm jitted code, but not including register
handler for handling exception only, because there is no backward compatibility
to maintain for Windows ARM64 which was released since 1709 windows build.
Bug: chromium:893460
Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63002}
Original CL:
> [wasm] Simplify module creation
>
> This includes WasmEngine::NewNativeModule() and
WasmModuleObject::New().
> The intent is to make the various ways of creating a module (sync,
> async, deserialize, import) more similar.
>
> After this change, a NativeModule will always be created before a
> WasmModuleObject. This will make it easier to look up a cached
> NativeModule given its wire bytes.
>
> The following changes are made:
>
> * Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
> size estimate by default. A different code size estimate is only
used in
> tests.
> * Change CompileJsToWasmWrappers() to allocate a new FixedArray
instead of
> assuming the array was created with the correct size. This
simplifies
> WasmModuleObject::New(), and matches what CompileToNativeModule()
> does.
> * Remove the WasmModuleObject::New() constructor that creates a
> NativeModule. This case was only used in DeserializeNativeModule()
and
> in test code.
>
> Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
> Reviewed-on:
https://chromium-review.googlesource.com/c/v8/v8/+/1717497
> Commit-Queue: Ben Smith <binji@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62925}
R=ahaas@chromium.org, clemensh@chromium.orgCC=binji@chromium.org
Change-Id: I03aa901a1df65af28f864d9aabe2b134ea132e99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724213
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62996}
The DCHECK related to a time when dictionary mode prototypes were the payload
of complex data driven handlers. Now the additional data is used to hold
entirely different kinds of objects. The DCHECK made no sense anymore. Cleaning
up the names makes this clearer.
Bug: chromium:986187
Change-Id: I7173d7d2824396c04c01acb4ceb74693ee9ce6b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724215
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62993}
This method will be used for a test with multiple code spaces, to
encode large function indexes. The current implementation in
{wasmI32Const} just always uses 5 bytes for encoding the LEB value.
This CL adds a {wasmSignedLeb} function which properly encodes the
value, and adds tests for that.
Drive-by: Clean up the rest of {test-wasm-module-builder.js}.
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: Ide2d90eed9d40aa28df680fbb413275346d9c0b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725623
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62990}
This patch adds:
- VariableMode::kPrivateMethod
- VariableMode::kPrivateSetterOnly
- VariableMode::kPrivateGetterOnly
- VariableMode::kPrivateGetterAndSetter
And replace the previous RequiresBrandCheckFlag by inferring
whether the brand check is required from these VariableModes.
It is then possible to check duplicate non-complementary
accessors in the parsers and throw early errors, and allow
complementary accessors to be associated with the same
private name variable.
This patch also adds the following AssignType:
- PRIVATE_METHOD
- PRIVATE_GETTER_ONLY
- PRIVATE_SETTER_ONLY
- PRIVATE_GETTER_AND_SETTER
corresponding to the new VariableModes so that it's possible
to generate specialized code for different type of
private accessor declarations.
Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
Bug: v8:8330
Change-Id: I0fb61b1be248630d1eadd74fb16d7d64a421f4c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695204
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62988}
The tests rely too much on OS state (thread allocation) to be
predictable.
Change-Id: I9a562369a3c72522630a23ee47e3e819b9411c65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725626
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62987}
On Windows, the FP stack registers are used with less precision.
This causes rounding errors in the uint64 to float32 conversion.
This CL replaces the implementation based on FP stack registers
with an implementation based on bit operations. This implementation
is 2x slower than the original implementation.
An alternative would be to change the precision of the FP stack
registers just for the uint64 to float32 conversion. However, in a
micro-benchmark this is 5-6x slower than the original implementation.
It is also not clear if changing the precision could cause side
effects.
R=clemensh@chromium.org
Change-Id: Iaab6b6f258ff01e0c6e93f3632daf516fae3e74b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708486
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62986}
Previously, this was run as a microtask and this CL changes it to run
as a separate task as mandated by the current WeakRef spec.
This CL also introduces a FinalizationGroup type to the V8 API
representing the JSFinalizationGroup. This has a `Cleanup`
function that runs the cleanup callback associated with it.
SetHostCleanupFinalizationGroupCallback is added to set
the embedder defined HostCleanupFinalizationGroupCallback.
ClearKeptObject is exposed on the v8::Isolate to reset the strongly
held set of objects.
The general workflow is the following:
(a) When the GC notices that a given finalization group has dirty
cells, it calls HostCleanupFinalizationGroupCallback with the given
finalization group.
(b) As part of HostCleanupFinalizationGroupCallback, the embedder
enqueues a task that at some point later calls
FinalizationGroup::Cleanup.
(c) At some point in the future, FinalizationGroup::Cleanup is called,
which runs the cleanup callback of the finalization group.
This patch also includes d8 changes to use these new APIs. Currently,
d8 cycles through the enqueued finalization groups after a synchronous
turn (and it's microtask checkpoint) and runs the cleanup callbacks.
Change-Id: I06eb4da2c103b2792a9c62bc4b98fd4e5c4892fc
Bug: v8:8179
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655655
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62984}
This drops possible remaining pattern errors from the access target. This is
necessary since sub patterns with default values (assignment expression) aren't
otherwise identifiable as being property accesses.
Bug: v8:9560
Change-Id: Ie6781c0d161e00790268f7d9db81377d045f93b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725624
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62982}
This allows to return bool values from Torque macros and branch on them
without performance penalty, reconstructing good control flow.
Drive-by cleanup: Delete EnsureDeferredCodeSingleEntryPoint(), since
it's no longer needed. Constructing a graph and then re-inferring
deferred blocks based on branch hints achieves this effect
automatically.
Bug: v8:7793
Change-Id: Idb6802372b407549e4760f290933d5b8f1e9d952
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1681132
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62979}
This reverts commit 4b15b984ad.
Reason for revert: UBSan failure (https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906578530303352544/+/steps/Check/0/logs/regress-126412/0).
Original change's description:
> [regexp] Better quick checks on loop entry nodes
>
> Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
> change is inspired by attempting to exit earlier from generated RegExp
> code, when no further matches are possible because any match would be
> too long. The motivating example this time is the following expression,
> which tests whether a string of Unicode playing cards has five of the
> same suit in a row:
>
> /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
>
> A human reading this expression can readily see that any match requires
> at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
> each repeated option reports its minimum distance to the end of a match
> as zero. This is correct, because the LoopChoiceNode's behavior depends
> on additional state (the loop counter). However, the preceding node, a
> SET_REGISTER action that initializes the loop counter, could confidently
> state that it consumes at least 10 characters. Furthermore, when we try
> to emit a quick check for that action, we could follow only paths from
> the LoopChoiceNode that are possible based on the minimum iteration
> count. This change implements both of those "could"s.
>
> I expect this improvement to apply pretty broadly to expressions that
> use minimum repetition counts and that don't meet the criteria for
> unrolling. In this particular case, I get about 12% improvement on the
> overall UniPoker test, due to reducing the execution time of this
> expression by 85% and the execution time of another similar expression
> that checks for n-of-a-kind by 20%.
>
> Bug: v8:9305
>
> Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62963}
TBR=jgruber@chromium.org,seth.brenith@microsoft.com
Change-Id: Iac085b75e054fdf0d218987cfe449be1f1630545
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9305
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725621
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62977}
This is a reland of a0728e869b
Original change's description:
> [d8] Remove maximum workers limitation
>
> This CL refactors the lifetime management of the v8::Worker C++ object
> and in the process lifts the 100 maximum worker limitation. To do this,
> it uses a Managed<v8::Worker> heap object and attaches the managed to
> the API worker object.
>
> R=mstarzinger@chromium.org
> BUG=v8:9524
>
> Change-Id: I279b7aeb6645a87f9108ee6f572105739721cef4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715453
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62932}
Bug: v8:9524
Change-Id: I7d903fb12ddb00909a9429455f46c55db2fd02de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722562
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62974}
We can get repeated positions from optimized code objects in some cases
but for our purposes of looking up a line number from a PC, we can only
return one line number so just use the first one that is reported in
the source position table on the code object.
Change-Id: I4c0e866fb1948f65bf6c988d992ef55f520dd874
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724375
Reviewed-by: Alexei Filippov <alph@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62972}
-0.0 and 0.0 compare equals, so a < b ? a : b for min would pick b
incorrectly. We need to use JS semantics here, which returns -0.0.
Bug: v8:8425
Change-Id: I8ab094b566ece9c586de86aad4594dfdf8da930b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724802
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62969}
Serialize for all cases of JSNativeContextSpecialization::ReduceJSInstanceOf.
Bug: v8:7790
Change-Id: I147991353b86619808257a92961b7051105511f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722558
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62965}
Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
change is inspired by attempting to exit earlier from generated RegExp
code, when no further matches are possible because any match would be
too long. The motivating example this time is the following expression,
which tests whether a string of Unicode playing cards has five of the
same suit in a row:
/([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
A human reading this expression can readily see that any match requires
at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
each repeated option reports its minimum distance to the end of a match
as zero. This is correct, because the LoopChoiceNode's behavior depends
on additional state (the loop counter). However, the preceding node, a
SET_REGISTER action that initializes the loop counter, could confidently
state that it consumes at least 10 characters. Furthermore, when we try
to emit a quick check for that action, we could follow only paths from
the LoopChoiceNode that are possible based on the minimum iteration
count. This change implements both of those "could"s.
I expect this improvement to apply pretty broadly to expressions that
use minimum repetition counts and that don't meet the criteria for
unrolling. In this particular case, I get about 12% improvement on the
overall UniPoker test, due to reducing the execution time of this
expression by 85% and the execution time of another similar expression
that checks for n-of-a-kind by 20%.
Bug: v8:9305
Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62963}
Fixes a bytecode mismatch for arrow functions with default arguments
between eager and lazy compilation. In the former case, parameters with
default values are marked as assigned even if the value never changes
within the function because the parser does not know it's an
arrow-function at the point it sees the assignment.
So this changes ArrowHeadParsingScope::ValidateAndCreateScope to clear
the is_assigned flag on its parameter VariableProxies before it binds
them.
Bug: chromium:988304, v8:8510
Change-Id: I68bf205c73471386181e5fdcec6c8c3b2e527c8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724384
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62962}
This is a reland of 658ff20085
Original change's description:
> [utils] Make BitField final
>
> We have hundreds of classes that derive from {BitField} without adding
> any functionality. This CL switches all such occurrences to 'using'
> declarations instead.
>
> Before:
> class MyBitField : public BitField<int, 6, 4, MyEnum> {};
> After:
> using MyBitField = BitField<int, 6, 4, MyEnum>;
>
> This might reduce compilation time by reducing the number of existing
> classes.
>
> The old pattern is forbidden now by making {BitField} final.
>
> R=yangguo@chromium.org
>
> Bug: v8:9396, v8:7629
> Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62956}
Bug: v8:9396, v8:7629
Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62959}
This reverts commit 658ff20085.
Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826
Original change's description:
> [utils] Make BitField final
>
> We have hundreds of classes that derive from {BitField} without adding
> any functionality. This CL switches all such occurrences to 'using'
> declarations instead.
>
> Before:
> class MyBitField : public BitField<int, 6, 4, MyEnum> {};
> After:
> using MyBitField = BitField<int, 6, 4, MyEnum>;
>
> This might reduce compilation time by reducing the number of existing
> classes.
>
> The old pattern is forbidden now by making {BitField} final.
>
> R=yangguo@chromium.org
>
> Bug: v8:9396, v8:7629
> Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62956}
TBR=yangguo@chromium.org,clemensh@chromium.org
Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9396, v8:7629
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62958}
We have hundreds of classes that derive from {BitField} without adding
any functionality. This CL switches all such occurrences to 'using'
declarations instead.
Before:
class MyBitField : public BitField<int, 6, 4, MyEnum> {};
After:
using MyBitField = BitField<int, 6, 4, MyEnum>;
This might reduce compilation time by reducing the number of existing
classes.
The old pattern is forbidden now by making {BitField} final.
R=yangguo@chromium.org
Bug: v8:9396, v8:7629
Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62956}
This makes function objects constructed via the {WebAssembly.Function}
constructor callable directly from JavaScript (not just from within
WebAssembly modules). Semantics are as if the function performed the
transition JS-to-Wasm and then Wasm-to-JS in sequence.
R=clemensh@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Ic7dcf36ccfda1b473f2541e49419f4d2ee38bc2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720809
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62953}
Implements ProfilerCodeObserver, a class to track the generation and
movement of code on the heap for the lifetime of each CpuProfiler. When
sampling is inactive, logged code is committed directly to the CodeMap.
During profiling, ProfilerCodeObserver redirects these events onto the
profiling thread for later dispatch.
Bug: v8:9151
Change-Id: Ib5b152446d2a3838e1b00a80253fc4fbd2f6e8c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1604143
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Cr-Commit-Position: refs/heads/master@{#62943}
This CL removes the built-in reference type in favor of a Torque-implemented generic struct, i.e., internal::Reference<T>. It also adds various infrastructure for getting and creating new generic struct instances, as well as matching against them.
R=tebbi@chromium.org
Change-Id: I1e3d6afe355a0603fa9c3ad789c6b8a97d1b3c26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718148
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62939}
This reverts commit a0728e869b.
Reason for revert: Times out on Windows & debug builds - https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/34484
Original change's description:
> [d8] Remove maximum workers limitation
>
> This CL refactors the lifetime management of the v8::Worker C++ object
> and in the process lifts the 100 maximum worker limitation. To do this,
> it uses a Managed<v8::Worker> heap object and attaches the managed to
> the API worker object.
>
> R=mstarzinger@chromium.org
> BUG=v8:9524
>
> Change-Id: I279b7aeb6645a87f9108ee6f572105739721cef4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715453
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62932}
TBR=mstarzinger@chromium.org,titzer@chromium.org,clemensh@chromium.org
Change-Id: I3a27937cba13b5413390f49268a107c184515153
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9524
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720590
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62937}
Use the position of commas in arrow expressions to mark the initializer
position of any parameters that might have been set in the preceding
parameter.
To enable this, this makes variable_list_ in ExpressionParsingScope a
ScopedList<pair<VariableProxy*, int>> and changes ScopedList::at to
return references so its elements can be modified in place.
This fixes a source of bytecode mismatches when collecting source
positions lazily and is a second attempt at fixing this after
https://chromium-review.googlesource.com/c/v8/v8/+/1683267 introduced
problems due to destructuring.
Bug: chromium:980422, chromium:981701, v8:8510
Change-Id: I948f89f34fb75d7463a13183e363f7f96ad09d13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710671
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62936}
This is short-term fix for flaky failures on GC fuzzer. The closures
g1 and g2 have the same SFI and pending optimzed table treats them as
a single entry. This cl, adds %PrepareFunctionForOptimize after one of
them is optimized.
Bug: v8:9556
Change-Id: I1fd72da1baa5de2f7650e080f9b6d04b69dd6a16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719188
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62934}
This CL refactors the lifetime management of the v8::Worker C++ object
and in the process lifts the 100 maximum worker limitation. To do this,
it uses a Managed<v8::Worker> heap object and attaches the managed to
the API worker object.
R=mstarzinger@chromium.org
BUG=v8:9524
Change-Id: I279b7aeb6645a87f9108ee6f572105739721cef4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715453
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62932}
... mostly by turning them into pointer arguments.
After this CL, all remaining non-const reference arguments in
the compiler directory are in the backend.
Bug: v8:9429
Change-Id: I6a546da0fe93179e1a0b12296632591cbf209808
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719185
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62930}
This reverts commit 425fa3ae15.
Reason for revert: test failure https://bugs.chromium.org/p/v8/issues/detail?id=9554 reverting the root cause has merge conflicts due to changes in same file
Original change's description:
> [wasm] Simplify module creation
>
> This includes WasmEngine::NewNativeModule() and WasmModuleObject::New().
> The intent is to make the various ways of creating a module (sync,
> async, deserialize, import) more similar.
>
> After this change, a NativeModule will always be created before a
> WasmModuleObject. This will make it easier to look up a cached
> NativeModule given its wire bytes.
>
> The following changes are made:
>
> * Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
> size estimate by default. A different code size estimate is only used in
> tests.
> * Change CompileJsToWasmWrappers() to allocate a new FixedArray instead of
> assuming the array was created with the correct size. This simplifies
> WasmModuleObject::New(), and matches what CompileToNativeModule()
> does.
> * Remove the WasmModuleObject::New() constructor that creates a
> NativeModule. This case was only used in DeserializeNativeModule() and
> in test code.
>
> Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717497
> Commit-Queue: Ben Smith <binji@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62925}
TBR=binji@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I8dcad7ddcd4601f657b6263bf22009907284fce3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719230
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62926}
This includes WasmEngine::NewNativeModule() and WasmModuleObject::New().
The intent is to make the various ways of creating a module (sync,
async, deserialize, import) more similar.
After this change, a NativeModule will always be created before a
WasmModuleObject. This will make it easier to look up a cached
NativeModule given its wire bytes.
The following changes are made:
* Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
size estimate by default. A different code size estimate is only used in
tests.
* Change CompileJsToWasmWrappers() to allocate a new FixedArray instead of
assuming the array was created with the correct size. This simplifies
WasmModuleObject::New(), and matches what CompileToNativeModule()
does.
* Remove the WasmModuleObject::New() constructor that creates a
NativeModule. This case was only used in DeserializeNativeModule() and
in test code.
Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717497
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62925}
- Move SerializePrototype out of DependOnStablePrototypes into
ComputePropertyAccessInfo.
- Brokerize JSNativeContextSpecialization::InferHasInPrototypeChain.
- Brokerize JSNativeContextSpecialization::ReduceJSOrdinaryHasInstance
(modulo the call to ReduceJSInstanceOf).
- Brokerize JSNativeContextSpecialization::ReduceJSHasInPrototypeChain.
- Serialize for JSCallReducer::ReduceObjectPrototypeIsPrototypeOf.
- Serialize for JSNativeContextSpecialization::ReduceJSInstanceOf. This
is still incomplete.
Bug: v8:7790
Change-Id: Ic56eab5ddd8d725a13d2980e5b55db53ae82e822
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709408
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@{#62920}
Per the July TC39 meeting consensus, we'd like to make the
upcoming String.prototype.replaceAll proposal throw for
non-global RegExp searchValues. However,
String.prototype.matchAll currently does not throw in this
case, causing consistency concerns.
This patch adds a use counter for String.prototype.matchAll
with a non-global RegExp as the searchValue. Hopefully, this
pattern isn't too common in real-world code today, in which case
we can both a) change matchAll and b) proceed with the desired
replaceAll semantics.
https://github.com/tc39/proposal-string-replaceall/issues/16
V8 CL: https://chromium-review.googlesource.com/c/v8/v8/+/1718145
Chromium CL: https://chromium-review.googlesource.com/c/chromium/src/+/1718367
BUG=v8:9551
Change-Id: Ica660a0a6189d84c3d33398c98305d0bcb9f8c23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718145
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62913}
This is a reland of c2ee4a7999
Original change's description:
> Reland "[regexp] Call the regexp interpreter without CEntry overhead"
>
> This is a reland of d4d28b73cb
>
> Original change's description:
> > [regexp] Call the regexp interpreter without CEntry overhead
> >
> > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
> >
> > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
> >
> > Bug: v8:8954
> > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
> > Commit-Queue: Patrick Thier <pthier@google.com>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62753}
>
> Bug: v8:8954
> Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Patrick Thier <pthier@google.com>
> Cr-Commit-Position: refs/heads/master@{#62794}
Bug: v8:8954
Change-Id: Ice77c05240f1fabd36bf97b8e789dd4c25a9718f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715451
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62904}
Add 'fluid-ounce','gallon', 'liter', and 'milliliter'
Also roll ICU to 682a2309
Sync with https://github.com/tc39/proposal-unified-intl-numberformat/pull/48
Bug: v8:9475
Change-Id: If45a20f17f5973b860893b0f70e724cc93c6550a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1699759
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62903}
This reverts commit 517ab73fd7.
Reason for revert: Test failures https://bugs.chromium.org/p/v8/issues/detail?id=9538
Original change's description:
> Add postmortem debugging helper library
>
> This change begins to implement the functionality described in
> https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
> for investigating V8 state in crash dumps.
>
> This change adds a new library, v8_debug_helper, for providing platform-
> agnostic assistance with postmortem debugging. This library can be used
> by extensions built for debuggers such as WinDbg or lldb. Its public API
> is described by debug-helper.h; currently the only method it exposes is
> GetObjectProperties, but we'd like to add more functionality over time.
> The API surface is restricted to plain C-style structs and pointers, so
> that it's easy to link from a debugger extension built with a different
> toolchain.
>
> This change also adds a new cctest file to exercise some basic
> interaction with the new library.
>
> The API function GetObjectProperties takes an object pointer (which
> could be compressed, or weak, or a SMI), and returns a string
> description of the object and a list of properties the object contains.
> For now, the list of properties is entirely based on Torque object
> definitions, but we expect to add custom properties in future updates so
> that it can be easier to make sense of complex data structures such as
> dictionaries.
>
> GetObjectProperties does several things that are intended to generate
> somewhat useful results even in cases where memory may be corrupt or
> unavailable:
> - The caller may optionally provide a type string which will be used if
> the memory for the object's Map is inaccessible.
> - All object pointers are compared against the list of known objects
> generated by mkgrokdump. The caller may optionally provide the
> pointers for the first pages of various heap spaces, to avoid spurious
> matches. If those pointers are not provided, then any matches are
> prefixed with "maybe" in the resulting description string, such as
> "maybe UndefinedValue (0x4288000341 <Oddball>)".
>
> Bug: v8:9376
>
> Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62882}
TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com
Change-Id: Ia078f2e8d101d2375b5db88021b2d65d28f1b075
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9376
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716033
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62899}
This change begins to implement the functionality described in
https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
for investigating V8 state in crash dumps.
This change adds a new library, v8_debug_helper, for providing platform-
agnostic assistance with postmortem debugging. This library can be used
by extensions built for debuggers such as WinDbg or lldb. Its public API
is described by debug-helper.h; currently the only method it exposes is
GetObjectProperties, but we'd like to add more functionality over time.
The API surface is restricted to plain C-style structs and pointers, so
that it's easy to link from a debugger extension built with a different
toolchain.
This change also adds a new cctest file to exercise some basic
interaction with the new library.
The API function GetObjectProperties takes an object pointer (which
could be compressed, or weak, or a SMI), and returns a string
description of the object and a list of properties the object contains.
For now, the list of properties is entirely based on Torque object
definitions, but we expect to add custom properties in future updates so
that it can be easier to make sense of complex data structures such as
dictionaries.
GetObjectProperties does several things that are intended to generate
somewhat useful results even in cases where memory may be corrupt or
unavailable:
- The caller may optionally provide a type string which will be used if
the memory for the object's Map is inaccessible.
- All object pointers are compared against the list of known objects
generated by mkgrokdump. The caller may optionally provide the
pointers for the first pages of various heap spaces, to avoid spurious
matches. If those pointers are not provided, then any matches are
prefixed with "maybe" in the resulting description string, such as
"maybe UndefinedValue (0x4288000341 <Oddball>)".
Bug: v8:9376
Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62882}
Preparing the value for storing into a typed array is user visible
operation in some cases (for ex: calling ToNumber). To avoid doing this
conversion twice pass the converted to the runtime when bailing out
from the handlers.
Bug: chromium:981236
Change-Id: I3de23d317d22cd6c201fe8a4db30014f4cf76251
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1692932
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62879}
This CL introduces generic Torque structs. Generics are grounded early in the Torque compilation pipeline, meaning that every instantiation of a generic struct with concrete types will be turned into a distinct StructType.
As an example, consider a Tuple of types T1, T2:
struct Tuple<T1: type, T2: type> {
const fst: T1;
const snd: T2;
}
which can be manipulated using generic macros, such as
macro Swap<T1: type, T2: type>(tuple: Tuple<T1, T2>): Tuple<T2, T1> {
return Tuple<T2, T1>{fst: tuple.snd, snd: tuple.fst};
}
Currently there is no type inference for struct instantiation sites, so type arguments have to be provided explicitly:
const intptrAndSmi = Tuple<intptr, Smi>{fst: 1, snd: 2};
R=sigurds@chromium.org, tebbi@chromium.org
Change-Id: I43111561cbe53144db473dc844a478045644ef6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714868
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62878}
This reverts commit 26dad80ff5.
Reason for revert: Breaks d8, see https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/22272
Original change's description:
> [d8] Cleanup message queues
>
> Simplifies some of the logic of message queues in d8 and makes sure
> to delete any in-flight messages upon worker termination. Drive-by
> cleanups of some other small d8 vestiges.
>
> R=clemensh@chromium.org
> BUG=v8:9524
>
> Change-Id: I587c0cb3eeed88107e7dba552389057f07c15c43
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710673
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62873}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: Ibc15d9fb76698a2bad51e3842392634fb2f0246b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9524
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714877
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62875}
Simplifies some of the logic of message queues in d8 and makes sure
to delete any in-flight messages upon worker termination. Drive-by
cleanups of some other small d8 vestiges.
R=clemensh@chromium.org
BUG=v8:9524
Change-Id: I587c0cb3eeed88107e7dba552389057f07c15c43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710673
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62873}
We now have branchful decompression so this needs to be updated. Also,
the sxtw doesn't happen so it is not included in the regex.
I don't know why this didn't block the other CL's submission.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: I7044878c4811f1ba39e957bfcb9bc9c77ccba172
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706482
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62872}
Also add tests for it.
Drive-by fix: Use ChangeInt32ToCompressedSmi since we have it
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: I45f04f8857acfc57b69eb4022a24ba082d28a91f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708480
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62871}
This will be used when the [[NewTarget]] is from another realm and
it's prototype is not an object.
Bug: v8:8179
Change-Id: Ic69db3cd95753c77ef6f1e677e71e1e20da0a6c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714864
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62869}
This reverts commit 306cf40344.
Reason for revert: performance regressions / too near branch point
TBR=mslekova@chromium.org
BUG=v8:9380
Change-Id: If77630b73eafbf1190c823199fe2a34361da303f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714867
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62867}
A benign datarace can occur between the array buffer tracker and
using an arraybuffer as an asm.js memory. The former reads the
{is_shared} bit, which should never change, and the latter writes
the {is_asmjs_memory} bit, but no other bits. Since these bits are
packed into a single word, TSAN reports a race.
R=ulan@chromium.org
BUG=v8:9531
Change-Id: Icceff211368e13794b6678b5fd7748fb5b3235bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714647
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62866}
Reland after splitting large classes further.
es6/classes.js is large and causes timeouts and OOM on some of the
configurations.
Bug: v8:9246
Change-Id: I51952447eb6a6b46d78410d5d3798292f5a8d87d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706061
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62864}
With compressed pointers, `kArchStoreWithBarrier` is a 32-bit store instead of
64-bit, and this means the index has a differerent immediate range.
Bug: v8:7703
Change-Id: If61c8544b0da87ba2779ba2c1a6963b52e3e5d9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710674
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62861}
1. Fix formatToParts show "plusSign" for -0 by using signbit instead of < 0
2. Fix crash bug of formatToParts while notation is either "engineering" or
"scientific".
Bug: v8:9513
Change-Id: I36b0b995c157dc642b9c201694d0ac0bb0396988
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710148
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62856}
Previously, if the new length was less than the current length, we ignored
the "configurable" value and set the length as requested. We already threw
if the new length was greater than or equal to the current length.
New behavior matches the spec and other implementations.
Bug: v8:9460
Change-Id: Idb92fd121bdaa707f6abd2d2082628bbf3541b83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709336
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62855}
Port cd34523b9b
Original Commit Message:
With this CL we add proposal tests to the wasm-spec-tests. For this I
extended the update-wasm-spec-tests.sh script. Additionally to
generating the spec tests it does the following:
For each proposal it identifies those tests that are different to the
spec tests, and then copies those tests also to the wasm-spec-tests
directory.
Additionally I adjusted the test runner of the wasm spec test to
run the proposal tests with the correct flags.
R=ahaas@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ia976d8017cacb61b46fe076c39ade6bc6137b7e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708989
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#62853}
Added if statements to check if VECTOR_FACILITY are supported in order to avoid “illegal instruction” errors during SIMD tests on old s390 machines.
Change-Id: I1ab841db02e6c47de54d4a15b973e5366f88e117
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704937
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#62852}
This is a reland of bc33f5aeba
Original change's description:
> Reland "[arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of 31cd5d83d3
>
> 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}
>
> Bug: v8:9380, v8:9221
> Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62809}
Bug: v8:9380, v8:9221
Change-Id: I9a2525753ae2424108d074fa81df5f25d945c824
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709409
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62847}
This adds a simple test calling:
generate-bytecode-expectations --check-baseline
It's added on one CQ and one CI builder. The infra side specifying the
command line landed here:
https://crrev.com/c/1709454
For the command to succeed on swarming we instruct the isolate server
to archive the executable alongside with all the *.golden files needed
for the --check-baseline command.
Bug: v8:9520
Change-Id: I358ca7a7142c0fdaa7f6960515e524729a481394
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709424
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62844}
1. Sync with
https://github.com/tc39/proposal-unified-intl-numberformat/pull/57
so the formatting of {style: "unit" unit: "percent"} and
the formatting of {style: "percent:"} are treated different that
simplified the algorithm.
2. Store style into bit flags because we need it quickly during format.
3. Add more unit tests and regression test.
Bug: v8:9498
Change-Id: I75ed22fef1feb73ebf624bda70ebe45b80e7bc8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704948
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62834}
Fix CheckBaselineExpectations returning 2 when it can't read its input
file. Since this was originally just in main, convert it to std::exit.
Change-Id: I70ae6fbc6e5e12b748d2ab1cc83b1deb67a8f861
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710659
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62833}
In InterpreterCollectSourcePositions tests always unset
FLAG_stress_lazy_source_positions as the tests cannot work with it due
to assuming that source positions won't be collected immediately after a
normal compile.
Bug: v8:8510
Change-Id: I194ed06c59336f5af3b7b2113a12c1a21dd6bcac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709425
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62832}
Adds a new out param which allows accessing the ScriptOrModule
of a function, which allows an embedder such as Node.js to use
the function's i::Script lifetime.
Refs: https://github.com/nodejs/node-v8/issues/111
Change-Id: I34346d94d76e8f9b8377c97d948673f4b95eb9d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1699698
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62830}
This is a reland of e55e0aa5bd
Original change's description:
> [runtime] Fix protector invalidation
>
> Protectors trigger when special properties are modified or masked. Previously
> we would check whether the property stored on the holder would invalidate the
> protector. Stores to to the receiver rather than the holder, however, so this
> CL changes holder for receiver, and adds additional checks that were missing.
>
> Bug: v8:9466
> Change-Id: I81bc3d73f91381da0d254e9eb79365ae2d25d998
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708468
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62805}
Tbr: leszeks@chromium.org
Bug: v8:9466
Change-Id: I693c73577ca9a35a271f509770cc1c87e5cc4b73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709420
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62829}
This makes sure the language mode of the module is correctly propagated
through the WebAssembly module, so that exported functions are allocated
with the correct language mode. It extends the existing {ModuleOrigin}
enum to consist of three values now.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-985154
BUG=chromium:985154
Change-Id: Id7b566738b1e710cc5001b894022bcd0f2c01bc3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708484
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62826}
Add a new mode to generate-bytecode-expectations to be used in a coming
test that tests that the bytecode expectations generated by
--rebaseline match the current state.
Change-Id: Ic03787cd853f9bf7d9b4412f96a767036c848c61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708477
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62825}
This reverts commit c2ee4a7999.
Reason for revert: webgl_conformance_tests deqp/data/gles2/shaders/conversions.html crashes on Android FYI Release (Nexus 9)
See https://bugs.chromium.org/p/chromium/issues/detail?id=985624
Original change's description:
> Reland "[regexp] Call the regexp interpreter without CEntry overhead"
>
> This is a reland of d4d28b73cb
>
> Original change's description:
> > [regexp] Call the regexp interpreter without CEntry overhead
> >
> > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
> >
> > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
> >
> > Bug: v8:8954
> > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
> > Commit-Queue: Patrick Thier <pthier@google.com>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62753}
>
> Bug: v8:8954
> Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Patrick Thier <pthier@google.com>
> Cr-Commit-Position: refs/heads/master@{#62794}
TBR=jgruber@chromium.org,petermarshall@chromium.org,pthier@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8954, chromium:985624
Change-Id: I5bc2c397a09979f42f28670f80a5366f2a33d80f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709411
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62824}
Fix a cctest/test-bytecode-generator/PrivateMethods mismatch between the
PrivateMethods source string and the snippet in the golden file due to
missing newline at the end of the string. Change C++ raw string back to
a normal string since in this case it makes it harder to see the
problem.
Change-Id: I3bea8873d37fbacac65548be8261f6b04104132f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709413
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62823}
This adds decoding and compilation of the "atomic.fence" operator, which
is intended to preserve the synchronization guarantees of higher-level
languages.
Unlike other atomic operators, it does not target a particular linear
memory. It may occur in modules which declare no memory, or a non-shared
memory, without causing a validation error.
See proposal: https://github.com/WebAssembly/threads/pull/141
See discussion: https://github.com/WebAssembly/threads/issues/140R=clemensh@chromium.org
TEST=cctest/test-run-wasm-atomics/RunWasmXXX_AtomicFence
BUG=v8:9452
Change-Id: Ibf7e46227f7edfe5c81c097cfc15924c59614067
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701856
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62821}
This reverts commit bc33f5aeba.
Reason for revert: Still failing (OOM on win32): https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/22210
Original change's description:
> Reland "[arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of 31cd5d83d3
>
> 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}
>
> Bug: v8:9380, v8:9221
> Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62809}
TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,titzer@chromium.org,gdeepti@chromium.org,mlippautz@chromium.org
Change-Id: Iea755df9aaa1e95d284135bd0a6681b1340b6832
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/+/1708487
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62811}
Previously both tracing implementations would be run side-by-side when
perfetto was enabled with the V8_USE_PERFETTO build flag. This CL
makes them run separately.
Both implementations now use the trace file provided by the user in D8
or the default v8_trace.json.
Add tests for perfetto events (which must be tested differently
due to the proto output format).
Drive-by fix: Fix pass-by non-const ref in GetJSONStrings.
Remove the TraceEvent struct for testing; we can just store a copy of
the protobuf directly.
Bug: v8:8339
Change-Id: Id50003e0f96e44b99a63a26693da6bdaca989504
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1702619
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62810}
This is a reland of 31cd5d83d3
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}
Bug: v8:9380, v8:9221
Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62809}
This reverts commit e55e0aa5bd.
Reason for revert: speculative revert for tsan breakage
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8907588363297935904/+/steps/Check__flakes_/0/logs/regress-437713/0
Original change's description:
> [runtime] Fix protector invalidation
>
> Protectors trigger when special properties are modified or masked. Previously
> we would check whether the property stored on the holder would invalidate the
> protector. Stores to to the receiver rather than the holder, however, so this
> CL changes holder for receiver, and adds additional checks that were missing.
>
> Bug: v8:9466
> Change-Id: I81bc3d73f91381da0d254e9eb79365ae2d25d998
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708468
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62805}
TBR=leszeks@chromium.org,verwaest@chromium.org
Change-Id: Id8fc36525b7c5631589a67073ad1fd5815ea2775
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9466
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708482
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62807}
Protectors trigger when special properties are modified or masked. Previously
we would check whether the property stored on the holder would invalidate the
protector. Stores to to the receiver rather than the holder, however, so this
CL changes holder for receiver, and adds additional checks that were missing.
Bug: v8:9466
Change-Id: I81bc3d73f91381da0d254e9eb79365ae2d25d998
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708468
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62805}
With a write barrier, stores with negative offsets would allocate a temporary
register to hold the offset when the `str` instruction is able to encode it.
For instance, when writing the object map:
```
;; This could be 'str x2, [x5, #-1]'
movn x4, #0x0
str x2, [x5, x4]
and x16, x5, #0xfffffffffffc0000
ldr x16, [x16, #8]
tbnz w16, #2, #+0xba8 ; Jump out-of-line
```
The reason behind this is that the out-of-line code uses an 'add' instruction on
the offset to compute the field address, putting pressure on the instruction
selector to make sure the immediate fits in both 'str' and 'add'.
But, this is not necessary since the macro-assembler is able to turn the 'add'
into a 'sub' or use a temporary register if needed.
Change-Id: I8838e4b81a0c0c1f90aa3d67861a9da1a6dfed06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708471
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#62803}
This test fails in --stress-opt mode because backing stores of
memories/arraybuffers that are postMessage()'d leak in d8. In normal
mode, only ~16 memories are allocated, which is not enough to OOM,
but in stress mode, it can be 5x that number. Should be fixed
by upcoming ownership changes.
BUG=v8:9380
R=clemensh@chromium.org
Change-Id: Iecec07d15339cf43b23f128f13d570dfe3b32130
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708475
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62802}
If we flush the bytecode from a SFI we might recompile a JSFunction while the function
still has its old feedback vector. This should usually be fine since the new and old
feedback vectors have the same layout, however some bugs in the parser mean that it's
possible for eagerly and lazily compiled eval functions to have different bytecode and
so potentially different feedback vector layouts.
For now reset the feedback vector if it doesn't have the same size when we compile the
JSFunction, and recreate a new one of the correct layout. This will be replaced with a
CHECK once the parser bugs are fixed.
BUG=chromium:984344,v8:9511
Change-Id: Ib8976f2541516f7a07e4d4ab7dc3c750dfe9b5d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708474
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62800}
When the main thread contributes to an item parallel job and runs
an item parallel task, it currently emits a background GC trace event.
That is confusing and may lead to incorrect accounting of main thread
GC time. This patch fixes it by introducing a 'Runner' parameter
to ItemParalllelJob::Task::RunInParallel and emitting a foreground
GC event if the runner is the main thread.
Bug: v8:9508
Change-Id: I755751bfe9eef427666d5f16fb50aa6093059e80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706485
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62798}
With recent spec changes, table.copy of length 0 does not trap anymore,
and we copy backwards whenever src < dst.
R=binji@chromium.org
Change-Id: I48e2b65083565631abc41bf4fdf4971f80fdf440
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706471
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62797}
This is a reland of d4d28b73cb
Original change's description:
> [regexp] Call the regexp interpreter without CEntry overhead
>
> Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
>
> This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
>
> Bug: v8:8954
> Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
> Commit-Queue: Patrick Thier <pthier@google.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62753}
Bug: v8:8954
Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@google.com>
Cr-Commit-Position: refs/heads/master@{#62794}
Adding two small builtins pushed this test over the OOM threshold,
so we disable it for now.
Bug: v8:9488
Change-Id: I6c0696c260cd8ef9e6ee59caec4848aab439fdf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706049
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62783}
If multiple isolates are involved, we can run OOM when creating many
wasm memories, because we only trigger GC in one isolate at a time.
TBR=titzer@chromium.org
No-Try: true
Change-Id: I037b5a13c670c5da2abe54b5045df94637c94f72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706484
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62782}
By having the proposal tests now as part of the wasm-spec-tests, we do
not need them here anymore.
R=clemensh@chromium.orgCC=binji@chromium.org
Change-Id: I2530a4d2e2e8caa6fe8ef4d7e7b8b6da550a5134
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706475
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62778}
With this CL we add proposal tests to the wasm-spec-tests. For this I
extended the update-wasm-spec-tests.sh script. Additionally to
generating the spec tests it does the following:
For each proposal it identifies those tests that are different to the
spec tests, and then copies those tests also to the wasm-spec-tests
directory.
Additionally I adjusted the test runner of the wasm spec test to
run the proposal tests with the correct flags.
CC=binji@chromium.orgR=clemensh@chromium.org
Bug: v8:7581
Change-Id: Idb7aa3c0a468ddb65b2ef3421def836561579cd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706470
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62777}
