Implementations are added to macro-assembler to be shared between
liftoff and code generator.
Change-Id: Ibe326a80f71cad41dadbb62ebbcb9b8797f1871f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3384540
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78593}
The field is updated on the main thread and read on threads using
LocalHeap to possibly trigger GC in fuzzing configurations.
Bug: chromium:1286699
Change-Id: I15330b7542358ce1a2307a1f258655126b252c03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383776
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78591}
The last update (using tools/wasm/update-wasm-fuzzers.sh) was in
November 2020, thus update again to add modules from all existing tests
to the corpus used by ClusterFuzz.
This increases the number of files in the corpus from 47196 to 53779.
R=ahaas@chromium.org
Change-Id: Ie293bda0b4d5d7c34d5b7c53d8115d9d3883f1db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379813
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78590}
We might run TRACE_GC with ThreadKind::kMain not only on each isolate's
main thread but also on the shared isolate's thread during a shared GC.
The DCHECK is too restrictive for the latter case. This is safe because
the shared GC will stop all main threads before starting its work.
Bug: v8:11708
Change-Id: I1f40140d6502b1ec797dfa783fb693ed213efb3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380522
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78588}
Provide a stub `third_party_heap::Heap` implementation to work around
linker erors with Visual Studio.
Refs: https://github.com/bnoordhuis/v8-cmake/pull/50
Bug: v8:10427
Change-Id: I435081d8cb195d1db999db699df3d3751663c81d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366367
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78587}
CDP has a "ExceptionDetails" structure that is attached to various
CDP commands, e.g. "Runtime#exceptionThrown" or "Runtime#evaluate".
The stack trace in the "ExceptionDetails" structure is used in
various places in DevTools. The information in the "ExceptionDetails"
structure is extracted from a v8::Message object. Message objects
are normally created at the exception throw site and may augment
the error with manually inspecting the stack (both to capture a fresh
stack trace in some cases, as well as to calculate location info).
The problem is that in some cases we want to get an "ExceptionDetails"
structure after the fact, e.g. when logging a JS "Error" object in
a catch block. This means we can't reuse Isolate::CreateMessage as
the JS stack at call time is unrelated to the time when an Error
object was thrown.
To re-use some of the code, this CL introduces a new
"CreateMessageFromException" method that is only available from the
debugging interface (not public V8 API!). The new method works
similar to Isolate::CreateMessage, but:
1) Does not look at the current JS stack, neither for a fresh
stack trace nor for location information.
2) Only uses the "detailed" stack trace for location info.
This is because the "simple" stack trace could have already
been serialized by accessing Error#stack.
Bug: chromium:1278650
Doc: https://bit.ly/runtime-get-exception-details
Change-Id: I0144516001c71786b9f76ae4dec4442fa1468c5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3337257
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78586}
Strengthen the assertion in CallFunction, that only callable functions
(not class constructors) are passed.
Change-Id: I2dc2d061cdc9930b5b8926285f021f9772e97570
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380529
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78585}
This is a reland of 86038ecfdc
Compared to the previous CL this one is adding a TSAN suppression
for GlobalSafepoint::EnterSafepointScope. local_heaps_mutex_ of client
isolates may be locked in any order. This would be detected by TSAN as a
potential race. Add some additional DCHECKs to compensate for that
missing test coverage.
As a cleanup this CL also removes the unused methods ContainsLocalHeap()
and ContainsAnyLocalHeap() from LocalHeap.
Original change's description:
> [heap] Optimize time to reach global safepoint
>
> Initial support for global safepoints kept it simple by entering a
> safepoint for each of them one after another. This means
> time-to-global-safepoint is the sum of all time-to-safepoint operations.
> We can improve this slightly by splitting up the safepoint iteration
> into two operations:
>
> 1) Initiate safepoint lock (locks local_heaps_mutex_, arms the barrier
> and sets SafepointRequested flag for all client threads)
> 2) Block until all runnning client threads reach a safepoint
>
> We now perform operation 1) for all clients first and only then start
> with operation 2).
>
> Bug: v8:11708
> Change-Id: Iaafd3c6d70bcf7026f722633e9250b04148b3da6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310910
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78308}
Bug: v8:11708, v8:12492
Change-Id: I7087ba23c08f2d4edb9b632eef3c218fc76342e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328786
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78583}
- Add an ActiveSuspender root, similar to the ActiveContinuation root.
- Add the missing "parent" field to the Suspender, which points to the
outer Suspender when they are nested, and update that field when
entering a new Suspender.
- Add the missing "state" field and update it when the state of the
Suspender changes.
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: I7a95f44f81390a347c6ef252ec6184fb4f0b0455
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345003
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78582}
This CL contains minor refactorings to some parts of the garbage
collector:
- Space iterators.
- Removes a redundant call to Heap::CreateFillerObjectAt.
- Heap::CompleteSweepingFull now ensures that sweeping in the C++
managed heap is also completed.
- Checks, comments and code cleanup.
Change-Id: I14a7fe45c270c463c94c86f45b0e65757249d548
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3377125
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78581}
This CL doesn't change behavior, only refactors MemoryAllocator:
* De-templatify class, MemoryAllocator is used on slow path and doesn't
really need templates for performance.
* Rename FreeMode names
* Move methods into private section of class
Change-Id: I7894fba956dcd7aa78ad0284d0924662fef4acae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379812
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78580}
The Isolate might not be aware that remapped builtins are used (see
Code::OffHeapInstructionStart()), so always try to lookup PC in the
remapped builtins if they are available.
Bug: chromium:1241665, v8:11460
Change-Id: Iefc373cf0ea0110c8c002b7677e6a1fd8fd45319
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379817
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78579}
We introduce {ConstantExpression}, which represents the most frequent
constant expression types directly, and falls back to a {WireBytesRef}
for the rest. During module decoding, we decode the most common
expressions separately and store them as {ConstantExpression}, so we do
not have to decode them again during module instantiation.
Bug: chromium:1284557
Change-Id: Ie411bbe9811d0d9f6e750ba202bb0ccff801dfee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3378347
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78576}
To make sure print the correct gc_count in heap layout tracer.
Change-Id: I790d9359acab188bbfd1f59b731531c58713d8f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361842
Auto-Submit: Jianxiao Lu <jianxiao.lu@intel.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Jianxiao Lu <jianxiao.lu@intel.com>
Cr-Commit-Position: refs/heads/main@{#78575}
It is possible for KeyedDefineOwnICKind to go into
ElementsTransitionAndStoreIC_Miss when a computed field key
is a valid index and the lazy feedback allocation is disabled.
Bug: chromium:1277863
Change-Id: If8a81384257647426607495b6e3d8f235913e8f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322634
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78573}
Vector load/store lane, splat, extend as well as load 32/64 zero
have been rewritten to make use of new z15 instructions (or use
older instructions if not available) in such Cls:
https://crrev.com/c/3138212https://crrev.com/c/3144373
Same has been done for PPC BE (AIX).
As a result the workarounds in wasm-compiler are no longer needed.
Change-Id: I1de7066fa20f6e4d9d68c1a6db77a164dc8ae2f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379820
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78572}
This is a temporary solution so prototyping of shared structs and shared
strings can be worked on in parallel.
Bug: v8:12007
Change-Id: Ic849ec66da1d3824d50d695f16e4b77380afa015
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379222
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78570}
V8 crashed with a FATAL when memory allocation during instantiation
failed. With this CL, a RangeError is thrown instead.
This is not the only possible OOM that can happen during the startup of
a WebAssembly app, but since the allocation of WebAssembly memory is
among the biggest allocations, this change may already prevent several
crashes.
R=clemensb@chromium.org
Bug: chromium:1268898
Change-Id: I9376830ba2fe9df62b5595b6b19c92e35a75dfda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380586
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78569}
Windows requires additional writable page to be allocated in front of
the code range, but at the same time the code range must not cross 4 GB
boundary in order to make Code pointer compression work for Code
pointers. All these constraints make the logic of hint calculation too
dependent on what VirtualMemoryCage::InitReservation() would do with
the provided hint. This CL simplifies the hint calculation and fully
relies on VirtualMemoryCage::InitReservation() to do the right thing.
On Linux the implementation of OS::GetFreeMemoryRangesWithin() doesn't
work when Chromium sandbox is enabled, so we use the beginning of the
preferred short builtin calls region as a hint. It should be at least
as good as the fallback hint but with higher chances to point to free
address space location.
Bug: v8:11880
Change-Id: I0b6ebec98dd0cf483f67e6ba8a919deb9ce7cc25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380585
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78568}
This CL takes advantage of the P9 `vector byte-reverse`
instructions to add to support to BE platforms.
Change-Id: Ia022e056ca61373b7f8f7754ec76e94774b80af3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3378922
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78566}
We introduce a type arrayref, which is a supertype of all array types
and a subtype of dataref. We change array.len to accept values of type
(ref null array).
Drive-by: Fix kEq/kData case in TypecheckJSObject.
Bug: v8:7748
Change-Id: I47c6a4487ddf5e7280c1427f43abe87a97c896bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3368105
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78565}
The original CL introduced a test that does not work when it is executed
concurrently on multiple isolates. This CL skips this test
configuration.
Original change's description:
> [wasm] Lazy compilation after deserialization
>
> The serialization format contains one boolean flag per function which
> specifies whether the function code exists in the serialized module or
> not. With this CL, this boolean flag is extended to a three-value flag
> which indicates whether the function exists, and if not, whether the
> function was executed before serialization. This information can then be
> used upon deserialization to compile only those functions that were
> executed before serialization.
>
> Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
>
> Bug: v8:12281
Change-Id: I36ce90b37736172aa01c47ab04e154ec8ea2d8aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380590
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78564}
This leads to a noticable performance improvements, and this flag
is flipped to "is_debug" by the V8 Autoroller in release branches
for the GN builds, so this change matches that behavior.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Change-Id: I0a6d9798617939f822a6ce347ed2005b1597627a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380246
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78561}
- Add Suspender.suspendOnReturnedPromise method
- Extend the WasmApiFunctionRef data with the suspender
- Detect wrapped WasmJSFunctions when we resolve the import
For now the generated wrapper is still a regular wasm-to-js wrapper, but
this sets the ground for generating specific wrappers for functions
wrapped by suspendOnReturnedPromise, and to access the suspender from
the wrapper code.
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: I81cbec6b023507e47e6e1463b5f9b912f807da6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345000
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78560}
BaseSpace classes. So BaseSpace should have a virtual destructor
for memory to be freed properly.
cppgc: :internal::RawHeap maintains a std::vector of
std: :unique_ptr<BaseSpace> and stores there different derived from
Change-Id: Id9f59817799303bf62aafb66b3a29770bbd2af1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379228
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Alexey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78558}
The methods in the v8::internal::Factory deal with creating the objects
described in src/objects, so there's no point in having different sets
of owners for them.
Bug: none
Change-Id: I05b48535bd81d37796e3f741156a059be8554759
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359634
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78557}
This simplifies integration with Bazel workspaces that already
have those libraries imported under different repository names.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Change-Id: Iee6dee1abb8fca10f6b998b2ec9f459c14376bc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3333633
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78552}
This allows other Bazel projects to use their existing zlib import,
and only pull compression utils from Chromium's zlib.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Change-Id: I1f88632dd07661312aa2aaf8716c1742c1f29c53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3375479
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78551}
This allows other Bazel projects to fetch those dependencies
without relying on a full "gclient" checkout.
Added "com_googlesource_chromium" prefix to repository names to
indicate that those are Chromium forks and not official releases.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Change-Id: I87272c3e8c28d14d8974cea144e457713c59d994
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3375478
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78550}
The enablement of PAC in Chromium will have two phases where support
will first be enabled on C++ code (e.g. Blink/Chrome/etc) and its
dependencies, followed next by support for dynamic code generated by
V8.
This change will allow enable PAC support for C++ code when V8
is built with Chromium.
Bug: chromium:919548
Change-Id: I8ebcbcfe3c2a3a38807b814f936272ac09625795
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372162
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Adenilson Cavalcanti <cavalcantii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78548}
This reverts commit fbcdb28178.
Reason for revert: New test fails for multiple (concurrent) isolates: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux/45152/overview
Original change's description:
> [wasm] Lazy compilation after deserialization
>
> The serialization format contains one boolean flag per function which
> specifies whether the function code exists in the serialized module or
> not. With this CL, this boolean flag is extended to a three-value flag
> which indicates whether the function exists, and if not, whether the
> function was executed before serialization. This information can then be
> used upon deserialization to compile only those functions that were
> executed before serialization.
>
> Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
>
> Bug: v8:12281
> Change-Id: I465e31e5422fa45163256be0e6594045865f0174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364089
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78545}
Bug: v8:12281
Change-Id: If0e327d02e8257a4d1cfcf8b82381af11f28e91c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3377126
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78546}
The serialization format contains one boolean flag per function which
specifies whether the function code exists in the serialized module or
not. With this CL, this boolean flag is extended to a three-value flag
which indicates whether the function exists, and if not, whether the
function was executed before serialization. This information can then be
used upon deserialization to compile only those functions that were
executed before serialization.
Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
Bug: v8:12281
Change-Id: I465e31e5422fa45163256be0e6594045865f0174
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364089
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78545}
