This is a reland of commit 7bf94d0336
Changes since revert:
- Update string forwarding table with evacuated objects in mark compact.
- Always mark forward objects in string forwarding table.
Original change's description:
> [heap] Transition/Shortcut strings only during GCs without stack
>
> By limiting transitions of (shared) strings and shortcutting of
> Thin/Cons strings to GC withouts stacks, optimizing compilers can rely on
> the invariant that string maps do not change during a GC, allowing them
> to eliminate map checks and enable more aggressive optimizations.
>
> Change-Id: Ic9c9ed7b04b2ceed369484bf048965c083a9a693
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030578
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84347}
Change-Id: I1ab0965ff421635457a66fbe7f178d951afe4402
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4035240
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84424}
This is a reland of commit dc91addeefhttps://crrev.com/c/4042290 has fixed an issue with the sandbox
initialization on Windows which would lead to less available address
space in the sandbox. This reland further allows for a smaller backing
memory region for the ArrayBufferAllocator. Together, this should
guarantee that backing memory can always be allocated.
Original change's description:
> Reland "[sandbox] Improve the default ArrayBufferAllocator for the sandbox"
>
> This is a reland of commit f08547afd4
>
> All ArrayBufferAllocators now share a backend allocator which owns the
> backing memory. This fixes the address space exchaustion issues.
>
> 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: Ia52eeb695ad89cc6146807fda040281ac5fdaf59
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916640
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83502}
Bug: chromium:1340224
Change-Id: I196c66012e1c8418797d46c01fb7a3be4bcf7c0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4038262
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84423}
We now reserve the last page of the sandbox address space and make it
inaccessible. This ensures that any accidental access to e.g. the
EmptyBackingStoreBuffer constant will crash with an access violation.
Further, it also fixes an edge case scenario where the construction of
e.g. a DataView could lead to an invalid SandboxedPointer: if an
ArrayBuffer is located right at then end of the sandbox, constructing a
view onto it with offset=buffer.byteLength will lead to a pointer that
points just outside of the sandbox, causing a CHECK failure.
Bug: v8:1385733
Change-Id: I3fa68c0779d2c02511ff1dbbb07b79451b6cb206
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4034205
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84422}
This fixes a bug where the {types} vector automatically reserved
additional space, and by comparing with its capacity we failed to
register an out-of-bounds error.
Using capacity over size has led to bugs before, and using it correctly
(reserving as much space as needed manually) prevents vectors from
reserving space exponentially. Therefore we are switching to using size
for bounds checks instead.
Bug: v8:7748, chromium:1388942
Change-Id: I3cb8de4f113aaa6d70e45557161fd4c268861f1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4046221
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84419}
There exists a limit in the WebAssembly specification on the maximum
number of functions allowed in a module. For release builds the limit
seems high enough for now, but we got developer feedback that their
debug builds exceed this limit. To support these developers without
violating the specification this CL introduces a V8 flag that allows
to specify a custom limit. Developers can then increase this limit
locally for their debugging sessions.
R=clemensb@chromium.org
Bug: chromium:1380561
Change-Id: Ie65a47d49e9ca1d8b05617df0f46c187afef06e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027963
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84417}
We can only use auipc + add instr to get pc address.
Change-Id: I44d7dd1798c94d672bf506658c82c80de601a4af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4039240
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#84415}
Global/traced handles are only ever used with two callbacks:
* MarkCompactCollector::IsUnmarkedHeapObject
* IsUnscavengedHeapObjectSlot
IsUnscavengedHeapObjectSlot already works with shared heap objects
because it only applies to objects in the young generation.
This CL fixes MarkCompactCollector::IsUnmarkedHeapObject with shared
heap objects. E.g. a local GC isn't allowed to load markbits for
shared objects.
Bug: v8:13267
Change-Id: Id0fb9ed73409e384eed4c7168100a1bf40a06f94
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4044362
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84414}
... instead of computing them on the fly. This approach seems to
perform slightly better because it requires less code.
Bug: v8:7703, v8:11460
Change-Id: If31a06fbc748251c491c011e9e3f118665e20159
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020456
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84413}
Enable --shared-string-table and --struct-harmony on more fuzzers.
Bug: v8:13267
Change-Id: Iedea33f5c06563aac4d0f0d0eb880f7ee6208d9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4043902
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84412}
This reverts commit 8016f5c667.
Reason for revert: Causes https://crbug.com/v8/13521 (Cannot create a handle without a HandleScope (v8::HandleScope::CreateHandle())
Original change's description:
> [inspector] Pass the Context into terminateExecution
>
> Adding and removing the MicrotasksCompletedCallback should be
> associated with the microtask queue of the Context. We store the
> context as WeakPtr and always remove the callback when it completes
> regardless of the state of the debugger.
>
> BUG=v8:13450
>
> Change-Id: I40d623b05952575febfb76accc15512a38d14ab9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4004602
> Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84302}
Bug: v8:13521, v8:13450
Change-Id: Id772d192833e7adba7f4f80c28c437c336f792d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4043829
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Andrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84410}
With shared space (instead of the shared isolate), the AccessorInfo
implementation of SharedArray's length property is no longer threadsafe.
Until AccessorInfos can be put into shared or RO space, go back to
storing the length field as a per-instance in-object field, which is
unfrotunately a little wasteful.
Bug: v8:12547
Change-Id: I99c1cbf26047da48a4b4c11e14ab7def7d4e4f60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4039309
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84408}
Clear OLD_TO_SHARED slots in free memory after shrinking large objects.
This CL now clear all slots outside of the object and not just from
the next OS page boundary.
Since we are already here also stop clearing OLD_TO_NEW and OLD_TO_OLD
since they should already be cleared at this stage of the GC. Add
DCHECKs that this always holds. We also don't need to iterate large
code objects since we do not shrink such pages anyway.
Bug: v8:13267, chromium:1385717
Change-Id: I75f6e56a7c13974ce669bbba29262e95eb94d287
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4037981
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84407}
So far we parallelized the {WebAssembly.validate} function. After recent
refactorings, we can use the same parallelized logic for validing (only
lazy or all) functions during compilation.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: I38d48e1e48d83c8e63657abb7077aa8318cf94f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4037269
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84405}
From the documentation: "Applications not manifested for Windows 8.1 or
Windows 10 return false, even if the current operating system version is
Windows 8.1 or Windows 10". As such, the sandbox initialization logic
may incorrectly conclude that it is running on an older version of
Windows and fall back to a partially-reserved sandbox.
The check for the version is not really necessary: afterwards, we check
if we can create virtual memory subspaces, which will only be possible
on Windows if VirtualAlloc2 is available. That API is only available
since Windows 10, making the explicit version check redundant.
Bug: chromium:1368009
Change-Id: Id877dcfd6e384c6af94b571f37e70a115ead8dde
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4042290
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84404}
This factors out a call graph from the suspects collector which in
a future CL can be serialized as a partial call graph and later
merged.
Bug: v8:12660
Change-Id: Ie6f682195a900ba0711b8f828c63bf41f142f2b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4035131
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84403}
Currently, if a script is compiled on the main thread or deserialized on
any thread, and a matching Script object is found in the Isolate
compilation cache, the new content is merged into the existing Script.
This CL implements the same merging for scripts which were compiled by a
background task. I expect speed changes to be minimal, because merging
is only needed in a small minority of compilations. When needed, it
usually takes about 10% as long as the deserialization of the script,
which in turn is faster than compilation from source text.
This CL also removes some code which I added in preparation for merging
on a background thread in this case. Upon further discussion, we've
determined that the extra round trip to a background thread when the
main thread is likely just waiting for completion would do more harm
than good, and performing the compilation cache lookup from the
background thread would be quite cumbersome.
Bug: v8:12808
Change-Id: Ia7a14a739779ab658b505572d19df4ec489a078e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023904
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84402}
The validation paths during decoding and compilation should generate the
same error message. To achieve this, we move the {GetWasmErrorWithName}
function from the compiler to the decoder. As a drive-by, we replace the
{WasmFunction&} parameter by just an integer, because that is all we
need.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: I469dd871c7471c0f5af12c56e19b71be136557cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4037268
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84399}
The gap resolver issue that this was blocked on is fixed now.
R=clemensb@chromium.org
Bug: chromium:1269989
Change-Id: I1aa4566190dd9705bf5688f5c551923f6273f93e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4042243
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84398}
This CL implements Torque builtins for BigInt left shift and right
shift and truncates shift operations when the shift amount is a
constant.
- Propagate truncation if we know the operation is a left shift.
- Lower the operation to a word64 right shift if the lhs is Signed- or
UnsignedBigInt64 and we know the op is a right shift.
A side effect of truncating left shift is it will not throw a
BigIntTooBig exception in optimized code.
Bug: v8:9407
Change-Id: Ibd42cf897ef8a35f6addd09674faf409654d6d7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4028142
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84396}
Otherwise we may pass an out-of-bounds type to {IsSubtypeOf}.
Bug: v8:7748, chromium:1388938
Change-Id: Ifcbf31c68da40d7b7a365c9d756cd5fa81347291
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4040930
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84395}
Port 2f4397d652
Original Commit Message:
Tail calls generate parallel moves that don't preserve the stack
layout, which is not always correctly handled by the current
gap resolver algorithm. Introduce a more robust algorithm that
handles any parallel move.
Design doc:
https://docs.google.com/document/d/1WbX5B4ej9MzsJ28JS4J5cF2eiJhKyX39vAUB7GSA5YE/edit?usp=sharing
Also remove the move-splitting logic. The problem that it addresses
(swapping aliasing FP registers of different widths on arm) is already
handled by the new algorithm.
R=thibaudm@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I6122e9fa7543171eff91435de1804f3a788455f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4035332
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#84394}
This will allow us to reuse the function for validation only lazy
functions.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: I853ec0a39a4f383391bd7e3556c16e84d11df553
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4037642
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84393}
The interpreter does not implement WasmGC, hence always use Liftoff as
reference if WasmGC opcodes are enabled.
R=manoskouk@chromium.org
Bug: v8:13496, chromium:1387316
Change-Id: I29f496ebc1921c727c216dda763c1e9a63d6597b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4042288
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84392}
The test fails with multiple isolates because with the NativeModule
cache the second isolate can create an unexpected state for the first
isolate.
R=clemensb@chromium.org
Bug: v8:13503
Change-Id: Ic83d374c61703fdeb570b65b3c444ab0ae3cef8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4040929
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84391}
When creating the generator object, Ignition includes the
header object size.
The uses of debug-pos-offset, such as isolate.cc:AppendAsyncFrame,
expect that.
Bug: v8:7700
Change-Id: Idbe31802ac3ad6cbac7c5f7f7bd731132c358b61
Fixed: chromium:1387883
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4042664
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84390}
This adds an implementation for the {kRef} case in
{MakeDefaultArguments}.
R=jkummerow@chromium.org
Bug: v8:13496, chromium:1391168
Change-Id: I4c0e85b46c50f766816f799e80cf1afbe6fa258a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4042663
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84386}
This is a reland of commit 00db0fff8c
Fix missing update_feedback_count setting, and adding update feedback to
lazy deopt.
Original change's description:
> [maglev] Support call speculation disabling
>
> Add a FeedbackSource to DeoptInfo which allows the caller to specify
> that this deopt is part of call speculation, and that call speculation
> should be disabled for this call when the speculation fails. This is a
> mechanism to prevent deopt loops, also used by TurboFan.
>
> Bug: v8:7700
> Change-Id: I59b5db3956e074ec808b218c00ae85796455742e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030438
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84332}
Bug: v8:7700
Change-Id: I3dee2108495776d37417982ad593f6daa460919e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4042661
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84385}
Move the {ValidateAllFunctions} method out of the
{ModuleDecoderTemplate} and provide it as a separate function. This will
allow us to reuse it for validation during compilation.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: Ie72b5e0a531eecc298e515646320ad83a3f6b9ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4035979
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84384}
BranchElimination is currently broken in turboshaft, because when
duplicating a block that contains operations with multiple outputs
(OverflowCheckedBinop, Call, Change), if a Projection for this
Operation is in a later block, then the projection input won't be
alive, because we can't merge those operations with multiple outputs.
Fixing this will require re-thinking a bit how Call, CatchException
and CheckLazyDeopt work. For now, disabling BranchElimination is a
reasonable temporary solution.
Fixed: v8:13514, chromium:1391696, chromium:1386287
Change-Id: I71e8b6cc20701749e0c26638ac8c354393c8d426
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4042543
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84383}
1) Pass {WasmFeatures} by value, it's a single word.
2) Pass a {base::Vector} instead of {start} and {end} pair.
3) Remove a redundant constructor (just pass an empty wire bytes vector
instead).
R=thibaudm@chromium.org
Change-Id: I337c3c86960505ae23c88cb6adc5646a61111f76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030434
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84382}
In a follow up we want to introduce a mode for just collecting or
processing. In the infrastructure however, we still call the wrapper
script with old arguments on release branches. This ensures that
we stay backwards compatible.
Bug: v8:12660
Change-Id: I08da713719d10cb58c2cd5ea7f711570bd57572c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4035976
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84380}
