This reverts commit 178148045f.
Reason for revert: regresses JetStream2 a lot.
Original change's description:
> [runtime] Invalidate XxxIteratorLookupChain protectors
>
> ... when "return" property is added to respective iterator or might be
> added somewhere up the prototype chain.
>
> According to the iterator protocol the "return" callback must be
> called when iteration is aborted in the middle.
>
> Bug: chromium:1357318
> Change-Id: I36d81b90cfd40e417136ab97ec53ad7054f4df77
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916630
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83427}
Bug: chromium:1357318, chromium:1368400, v8:13335
Change-Id: I8b14a2c47819a89d9b2c869a7bcb52e2c2457427
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925199
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83466}
... exception.
Array#join depends array_join_stack to avoid infinite loop
and ensures symmetric pushes/pops through catch blocks to
correctly maintain the elements in the join stack.
However, the stack does not pop the elements and leaves in
an invalid state when throwing the uncatchable termination
exception. And the invalid join stack state will affect
subsequent Array#join calls. Because all the terminate
exception will be handled by Isolate::UnwindAndFindHandler,
we could clear the array join stack when unwinding the terminate
exception.
Bug: v8:13259
Change-Id: I23823e823c5fe0b089528c5cf654864cea78ebeb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3878451
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#83465}
... after gc.
This CL also adds a runtime test function GetWeakCollectionSize
to get the weak collection size.
Bug: v8:12947
Change-Id: I4aff39165a54b63b3d690bfea71c2a439da01d00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3905071
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#83464}
The `v8_control_flow_integrity` build flag was already on by default in
Chromium on those platforms, by depending on
`arm_control_flow_integrity`. We should also turn it on by default when
building V8 standalone.
Co-authored-by: Richard Townsend <richard.townsend@arm.com>
Bug: v8:10026, v8:12963
Change-Id: I361a6426f44e569c08c763cf84a687ca70b89f08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829068
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/main@{#83458}
This CL moves the code for requesting a GC from a non-main thread from
LocalHeap to Heap into CollectGarbageBackground().
The CL then makes use of this method in CollectGarbageShared() to
request a GC with --shared-space.
Bug: v8:13267
Change-Id: I2946cf5068ef8eb9eb99f9d396ac466d68abc7ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916634
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83456}
This change removes the confusing statement positions that were
previously emitted for every binding identifier within both array
and object destructurings. These statement positions were reported as
breakable positions to the debugger front-end, and during stepping, the
debugger would also stop on them. This is confusing and very different
from how other expressions work (we don't emit statement positions
within expressions normally).
Instead we emit expression positions for the binding identifiers, which
are used to construct the source positions for stack traces. As a drive
by we also add the missing position (and test cases) for sub-patterns.
In particular this aligns the stepping and breakpoint behavior around
destructuring expressions with that of Firefox DevTools.
We also remove the original test cases, introduced with
https://codereview.chromium.org/1542813003 and
https://codereview.chromium.org/1533313002, which were written as
debugger tests, with new inspector tests that also ensure that the
call positions are correct.
Fixed: chromium:1368444
Bug: v8:811
Doc: http://go/chrome-devtools:destructuring-breakpoints-design
Change-Id: I4d53ad059b5eede73abd01d9bc9fdf8263c55c9d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916453
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83455}
Fix a bug where merge point known_node_aspects was initialised with
empty aspects instead of a clone of the current state.
Bug: v8:7700
Change-Id: Ibdde32197873b4c04e5884dd55f90ead4c1199e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3921519
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83454}
Compacting pages in the shared space during Full GC requires a
corresponding shared space.
Bug: v8:13267
Change-Id: I1952c6b907847220018e2255956cc405fb88d144
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3918271
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83453}
When unicode sets (/v) are enabled, the regular expression is treated as
unicode, similar to /u.
Bug: v8:11935
Change-Id: I07dc617c1fcd9975ad5a3d226cec025c63489fd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3918417
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83452}
Implementation of property sequences for regular expressions is unused
(likely since switching to icu).
Bug: v8:11935
Change-Id: Ic4cf6219de8d6eb99464292a20f637e1fd423341
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3920135
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83451}
.. which can be inserted into the graph for easy int3 placement. Quite
often, this can be done in Foo::GenerateCode instead, but not always
(e.g. when multiple bytecode translate to the same Maglev opcode).
Bug: v8:7700
Change-Id: I6ffdf41f8dc4bd3c06e8323d33e92a5e6460de9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3921394
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83450}
This CL changes LocalsBlockListCacheSet/Get to handle the case when we
don't have an outer ScopeInfo. Instead of writing undefined/null into
the tuple we skip using the tuple alltogether and store the block list
directly as the value of the map entry.
The only purpose of stashing the outer ScopeInfo together with the
block list is to keep all the block lists of outer scopes alive as
well.
Doc: https://bit.ly/chrome-devtools-debug-evaluate-design
Bug: chromium:1363561
Change-Id: Ic8039072d62c1a99e23537d4702f1cd21d956121
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3920133
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83449}
Add VectorUnit clear in branch link and block start.
Bug: v8:13305
Change-Id: Ibe6fa03183d7fc21cde78c87db9f2550e8e88562
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3917324
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#83448}
For constants and smi-tagging, we have some static knowledge of the node
type, so warm-up the NodeType of NodeInfo in the Build*Check helpers.
Similarly, don't emit map checks for constant nodes that have a known
stable map.
Bug: v8:7700
Change-Id: I36e4d3000cf2f4dc689e8a9ab612a88dd751cdb5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3918770
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83443}
Also drive-by adds a test for toSpliced on an empty array.
Bug: chromium:1367651, v8:12764
Change-Id: I59ff19ef73dd6c5ea972dc6f39f1968858099ef8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3919870
Commit-Queue: Adam Klein <adamk@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83441}
It is possible, though unlikely, that V8 will deserialize code cache
data, decide to merge that new data with an existing script from the
Isolate compilation cache, and subsequently do nothing in the background
portion of the merge (make no heap changes, and request no follow-up
changes on the main thread). In this case, the most optimal outcome is
to reuse the script from the Isolate compilation cache, not to use the
newly deserialized script.
CodeSerializer::FinishOffThreadDeserialize uses
BackgroundMergeTask::HasPendingForegroundWork to determine whether it
should complete the merge and use the Script from the compilation cache
or complete the deserialization and use the newly deserialized Script.
This change updates HasPendingForegroundWork so that it will return true
even if the merge was a no-op.
Bug: v8:12808
Change-Id: I08fcb814e797218e5be2b4ce4f45bd4e0637ec80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916270
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83439}
The current Array#push reduction supports some amount of non-redundant
homogeneous from its receiver maps, and unifies polymorphism by
generating a push implementation per unique receiver elements kind,
rather than per receiver map. It does this by dynamically reading off
the receiver's elements kind, and branching on it.
Reading off the receiver's elements kind dynamically is a bit of a waste
though, since we already know the small subset of maps that are possible
at this point, and have probably emitted diamonds for checking those
maps which can't be merged with the dynamic elements kind lookup.
In this patch, this code is changed in two major ways:
1. We perform comparisons on the receiver map, rather than the
receiver elements kind, and dispatch to the per-elements kind
implementation after that check.
2. We allow the Smi path to fallthrough into the Object elements path,
once its Smi checks complete, to avoid generating distinct but
identical grow-and-set code for both PACKED_ELEMENTS and
PACKED_SMI_ELEMENTS.
Change-Id: Ie7764339a0220cb30aee0592553e0dc98539ac79
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3912765
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83438}
Those operators are not eliminable and need different properties than
the rest of loads/stores.
Bug: v8:12783
Change-Id: I7cd478fa827589612ca5d7628c628c09f3f4a3a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3909361
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83437}
Make Load/StoreHandler printing a bit more robust against unexpected
values, which we may have missed in the printing definition (or the
value is corrupt, or the caller of the print is passing the wrong value
in) -- for printing like this it's better to be able to not crash on
invalid state.
Change-Id: Ibf5c2064d6aac3da1ac6c19469fe31d5f761b6dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3918710
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83436}
This CL decouples the Wasm GC JS interop from the experimental
string <-> array conversions as the interop is now enabled by
default, still there are some issues discovered with the
conversions.
The functions are fixed via https://chromium-review.googlesource.com/c/v8/v8/+/3916633.
Bug: chromium:1366881
Change-Id: I27730523a51d24a7ea18199e1668e8c76f0bcb4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916088
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83435}
This introduces a new DirectHandle class with a deliberately similar API
to Handle. It uses an API that uses identical method names for symmetry,
but with an address field containing a direct pointer to JS heap objects
(or SMI).
Direct handles are experimental and can be enabled with the
v8_enable_conservative_stack_scanning gn option. The motivation for them
is described in the design doc [1].
[1]: https://docs.google.com/document/d/1uRGYQM76vk1fc_aDqDH3pm2qhaJtnK2oyzeVng4cS6I/
Bug: v8:13270
Change-Id: I0a6e0581adb5fa3b420efec3ba2b6d609d945c52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820483
Commit-Queue: Jake Hughes <jh@jakehughes.uk>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83434}
This CL fixes the build with neon intrinsics using clang-cl.
Seems it doesn't need to apply MSVC workaround for uint32x4_t and uint64x2_t.
Bug: v8:13333
Change-Id: Ic053a5c344de492458f9da749d81808775491dcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916643
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83433}
It's possible the path into resumable loop looks dead, while the loop
body itself is resumable and is being optimized due to an active
generator running the loop. By reviving resumable loop headers we have a
chance to properly optimize such generators (and avoid deoptimizing them
prematurely).
Bug: v8:7700
Change-Id: Icf5dadba17a7fd38409193e1e3f702f108a5639e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3918093
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83432}
Drive-by: dtype and stype are removed from SIMD_UNOP_LIST,
toSimd() requires them to all be of type `fp`.
Change-Id: Ifdfe187e2b143fb8fa785c44344bea38ea7e10f8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916553
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#83431}
ref.cast_nop is used for internal testing only.
0xfb48 will become ref.test null.
Bug: v8:7748
Change-Id: Iaee762dd97a993a361edddf656090210876178a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913205
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83430}
Non-well-behaved test cases may pass too few arguments. The builtins
shouldn't attempt to inspect arguments that aren't there.
Not bothering with a regression test because these experimental
builtins are probably short-lived at this point anyway.
Fixed: chromium:1366881
Change-Id: Ifee8929c6a97539eac7609c64082d66cd53cec89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916633
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83429}
... when "return" property is added to respective iterator or might be
added somewhere up the prototype chain.
According to the iterator protocol the "return" callback must be
called when iteration is aborted in the middle.
Bug: chromium:1357318
Change-Id: I36d81b90cfd40e417136ab97ec53ad7054f4df77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916630
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83427}
The GraphAssemblerLabel VarCount template parameter now can have a
marker value ~0 which is marker for it being dynamic sized -- this means
that a bit of template magic turns its std::arrays into std::vectors.
Merging GraphAssemblerLabels works by duck-typing access to these
arrays/vectors.
These dynamic GraphAssemblerLabels are created whenever a single
GraphAssemblerLabels being created when instead a list of values
convertible to MachineRepresentation is passed in. Passing anything else
will result in a GraphAssemblerLabel with marker value ~1, which is
considered "invalid" and will give a compilation error down the line.
std: :vector is passed into MakeLabel, with the static
Change-Id: I833bdedac2f8e26fcc88aa59dd67b7e4b1c4296d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913349
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83424}
When performing full GC on a shared space isolate, the GC also needs
to visit OLD_TO_SHARED slots in client isolates and update pointers.
Bug: v8:13267
Change-Id: Ida48c666dce8f5ed703a6920ad007add9235d64a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913347
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83421}
Collect feedback for BigInt64 in interpreter and change the runtime
for BigInt64 addition.
Bug: v8:9407
Change-Id: Ic69ba2c1f5ada998ac5ee3279e8296efe084d600
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3909809
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83419}
See also Turbofan's JSContextSpecialization reducer.
For all context loads and stores, this CL implements:
1) depth reduction through graph walks (even without FCS)
2) conversion from the context node to a heap constant
3) if possible, conversion of a load of an immutable context slot load
to a heap constant
Bug: v8:7700
Change-Id: Ie4d1acd0ff206f25dd5373a860d23b006a31dcee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3904914
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83418}
This reverts commit f08547afd4.
Reason for revert: Causes failures due to virtual address space
exhaustion inside the sandbox.
Original change's description:
> [sandbox] Improve the default ArrayBufferAllocator for the sandbox
>
> Rather than using a page allocator and rounding all allocation request
> sizes up to the next multiple of the OS page size, we now use a
> base::RegionAllocator with a "page size" of 128 as a compromise between
> the number of regions it needs to manage and the amount of wasted memory
> due to allocations being rounded up to a multiple of that page size.
> While this is still not as performant as a "real" allocator, it does
> noticeably improve performance when allocating lots of ArrayBuffers.
>
> Bug: chromium:1340224
> Change-Id: I56d1ab066ba55710864bdad048fb620078b2d8c2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913346
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83396}
Bug: chromium:1340224
Change-Id: I3e3cc18c0e75cac586b7f014a75df1028bbfa86f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916637
Commit-Queue: Samuel Groß <saelo@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83417}
