This makes sure that catch-blocks don't accidentally drop values that
are only in registers, which can happen if we throw in deferred throwing
code (e.g., in ThrowReferenceErrorIfHole). At the latest we'll discover
such values when trying to merge after the catch block, noticing we
can't find the value through the catch-block. Unfortunately it's not
trivial to figure out where that merge happens, so we just
unconditionally spill the value.
For liveness holes (as the comment previously mentioned) the value
should already be dead and dropped on the merge. Running --maglev-stress
etc shows that no code currently hits this path, except for the added
test that shows the issue with catch blocks.
Bug: chromium:1392061
Change-Id: Ied0b1d4b430c9af2e7ae3dfc004ecb45037c5735
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051605
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84448}
When promoting an object into the shared heap atomically updating the
map word to a forwarding pointer might fail when another thread is
faster. In such cases we need to replace the unused copy of that
object with a filler. We could also "undo" the last allocation in the
future but since this should be rare and hard to test don't do this
for now.
Bug: v8:13267
Change-Id: Ic608942e0c4fe8bd53d25b688875098474a34021
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051126
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84445}
A shared GC needs to reset weak global handles that store pointers
to shared objects which die during the shared GC.
Bug: v8:13267
Change-Id: I3800bf1173f42dd9ab96be4add462547b2a8f4a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051602
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84444}
When a ETW tracing sessions starts V8 emits events for all already
jitted functions. In very large apps this can cause a noticeable UI
jank. Most of this time is spent re-parsing all already jitted
functions to ensure that the source positions data for these functions
is available. But for ETW events we only need the initial location of
a function, not its full source position data, therefore we should be
able to omit the reparsing.
Bug: v8:11043
Change-Id: I9f1866464fdb8295ca2118de3ab1a72ce6e0f5b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4049920
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#84440}
In some situations we might want to start a global safepoint from a
shared isolate. However, Isolate::shared_heap_isolate() can't be used
on a shared isolate. This CL avoids this invocation for shared
isolates.
This CL also stops logging for the WasmEngine for shared isolates. A
shared isolate isn't added to the WasmEngine.
Bug: v8:13267, v8:13524
Change-Id: I58f6d81e61ce7dba619a4902afb50a6582161a66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4048481
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84439}
Complete sweeping time was accounted based on the GC that will be
started, not the GC that will be finished.
Bug: v8:12612
Change-Id: I2b914abf01be8eecfe7b4ec011d8893407867aef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051204
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84438}
This reverts commit 5e07bb70e5.
Reason for revert: --struct-harmony caused an initial flood of
bugs on the correctness fuzzer. Let's reland this once we've
sorted out those.
Original change's description:
> [heap] Enable shared heap flags on more fuzzers
>
> 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}
Bug: v8:13267
Change-Id: Id7973fa312cdddff6c49b672d0496c33fc8828e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051202
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#84436}
Skip whole table entry when the original string is the deleted element
sentinel.
When a string dies in young space, only the original string object in
the forwarding table is overwritten with the deleted element sentinel to
mark the whole entry as deleted.
When updating objects after evacuation during full gc, rows weren't
correctly skipped.
Change-Id: I76bac70acdb174c0a48cf876b1527f9de048b2ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051200
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84433}
Wine does not implement flipping PAGE_WRITECOPY pages to PAGE_READWRITE
after they're written to, and fails the CHECK in
base::OS::SetDataReadOnly.
Loosen the CHECK so that PAGE_WRITECOPY is also accepted as the previous
protection value.
Bug: v8:13512
Change-Id: Ifa42bb59e9dcc05c078841579fa32dd24470990a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4035093
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84431}
The test is slow and timeouts easily.
R=manoskouk@chromium.org
Bug: chromium:1380561
Change-Id: I413891a73daa1f2ef9d9537b35b8543495a0ccac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4048122
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84430}
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}
