When v8_enable_external_code_space is enabled the Code objects are
allowed only
- in CodeDataContainer::code field
- as uncompressed values embedded in Code instruction streams
Bug: v8:11880
Change-Id: I080a678fd77a7e42c6a397e7145a640fd07d6e83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2969828
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75275}
This reverts commit 0f90a2aa1c.
Reason for revert: Breaks MSAN, please see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/38941/overview
Original change's description:
> [wasm] Provide a global WasmCodeManager
>
> The WasmCodeManager was part of the WasmEngine so far, but there is only
> exactly one WasmEngine. Hence we can pull it out, and also remove the
> pointer in the WasmCodeAllocator.
>
> The argument passed from the single constructor call is now inlined in
> the constructor itself.
>
> Drive-by: Replace "GetPlatformPageAllocator()->CommitPageSize()" by just
> "CommitPageSize()".
>
> R=jkummerow@chromium.org
>
> Bug: v8:11879
> Change-Id: I6c0e74cea308f5806d1aa479945d90b6ef8d1613
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972909
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75270}
Bug: v8:11879
Change-Id: I110eec313762d73073f530aec7cf0be82c4db344
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972921
Auto-Submit: Maya Lekova <mslekova@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/master@{#75274}
Merges `NativeModuleModificationScope` (with an implementation using
Intel PKU, if available, and mprotect otherwise) and
`CodeSpaceWriteScope` (for Apple Silicon, where switching to RWX with
mprotect is disallowed anyway, so MAP_JIT and thread-local switching
must be used).
Because `CodeSpaceWriteScope` sounded better (and is shorter), we kept
its name (which unfortunately makes the diff a bit harder to read).
R=clemensb@chromium.orgCC=jkummerow@chromium.org
Bug: v8:11714
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Change-Id: Ib2a7d18e72797a725ed34b904c70769166d811dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972911
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Cr-Commit-Position: refs/heads/master@{#75272}
The WasmCodeManager was part of the WasmEngine so far, but there is only
exactly one WasmEngine. Hence we can pull it out, and also remove the
pointer in the WasmCodeAllocator.
The argument passed from the single constructor call is now inlined in
the constructor itself.
Drive-by: Replace "GetPlatformPageAllocator()->CommitPageSize()" by just
"CommitPageSize()".
R=jkummerow@chromium.org
Bug: v8:11879
Change-Id: I6c0e74cea308f5806d1aa479945d90b6ef8d1613
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972909
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75270}
The exception meta-data API created several objects in the wrong
context, resulting in the exception context being kept alive for
too long.
Bug: chromium:1221089
Change-Id: I02aece4e10d9bd559d49f98fe1c3e44a09e27eef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2975301
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75269}
... and OPTIMIZED_CODE_LIST and DEOPTIMIZED_CODE_LIST slots of
NativeContext which serve as heads of respective weak lists of Code
objects.
Drive-by: trivial NativeContext methods are moved to contexts-inl.h
header.
Bug: v8:11880
Change-Id: I0f2ca967b2820f84c279fea702bab28829f65d0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968416
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75268}
In an effort to merge `CODE_SPACE_WRITE_SCOPE` and
`NativeModuleModificationScope`, this CL moves the interface and
implementation of the latter into code-space-access.{h,cc}, where the
former already lives. No other changes to the code itself.
R=clemensb@chromium.orgCC=jkummerow@chromium.org
Bug: v8:11714
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Change-Id: I1aabce26f2033430523a7a3a0a4864e7267bee21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972803
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Cr-Commit-Position: refs/heads/master@{#75267}
There is exactly one WasmEngine per process, hence we do not need to
store or pass a pointer to it. We just use {GetWasmEngine} (which just
reads a global variable) whenever we need it.
R=jkummerow@chromium.org
Bug: v8:11879
Change-Id: I7e0e86e326f4cafe5a894af0ff6d35803c0340a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972725
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75266}
The WasmEngine is shared across the whole process, so there is no need
to store it in every Isolate.
Instead, we can just get it from everywhere on any thread using
{wasm::GetWasmEngine()}, which is a simple read of a global.
R=jkummerow@chromium.org
Bug: v8:11879
Change-Id: I13afb8ca3d116aa14bfaec5a4bbd6d71faa9aa17
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2969825
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75265}
Rolling v8/build: 11f1e3d..d6115b1
Rolling v8/buildtools/linux64: git_revision:d2dce7523036ed7c55fbb8d2f272ab3720d5cf34..git_revision:7d803996740ccd587c54062750cbe04dfbc3c423
Rolling v8/third_party/aemu-linux-x64: R61GnhotR5EpRE5ZeVtRvIQPRz8z-LSXnxN1ighigqMC..h_kO6UaQmxXGNfG0ofG4wgKw_URVHcderPkx6AlamR0C
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2573cff..893c99a
Rolling v8/third_party/depot_tools: 59140d4..473499b
Rolling v8/tools/clang: 66b4484..0e77445TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: I00eab552662eb15afd50c8b77ff72932806d443b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2973786
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#75264}
It will be used by consume_init_expr().
Bug: v8:11895
Change-Id: I577b5126a3c2cd0a6075ff9f085b4c93a8554846
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972906
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75259}
Bug: chromium:1221591
Change-Id: Ie24334873d1e66de0e0aa90fa1fb49d4290b7b59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2973214
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75255}
When we later introduce an additional template argument to WasmDecoder,
we will have to add it here too, as well as in all places which use
MemoryAccessImmediate. It is simpler to have a helper function in
WasmDecoder to fetch the 64-bit memory status.
Bug: v8:11895
Change-Id: I08edbf4e825cd148b30b2a5c0d04a26dfbaed186
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972905
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75252}
Split interface functions into constant, non-constant, and meta
functions. This will be useful once initializer expression decoding is
implemented as an interface for WasmFullDecoder.
Additionally, add ArrayInit() interface function (currently unused).
Bug: v8:11895
Change-Id: If076fe47871868c2d754f9c72c865f0a7f9f97d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964609
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75251}
Only print the property name when accessing null/undefined if we can
convert it to a string without causing side effects.
If we can't, omit the property name in the error message.
This should avoid confusion when the key is an object with toString().
E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
Object]' anymore, which was misleading since the property accessed would
be 'a', but we can't evaluate the key without side effects.
Bug: v8:11365
Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75250}
Set stack start as otherwise TracedReference from stack would not be
kept alive.
Bug: chromium:1220744, chromium:1056170
Change-Id: I99d54ac44b3f7cb4aa9732eb9260b918193a68e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972728
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75249}
Replace GetOwnDictionaryPropertyFromHeap with
TryGetOwnDictionaryPropertyFromHeap which will return {} if we are
trying to read out of bounds of the heap or the object. This is done so
that we can concurrently use the method.
We introduce a new compilation dependency (DependOnPropertyValueSame)
which checks that the background thread indeed read the correct value.
Bug: v8:7790
Change-Id: Ia5e308faf1f65add638cd271995f4f33416fbd15
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2930480
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75248}
In order to avoid unnecessary conversions to CodeT and back this CL:
- makes compiler::CompileCWasmEntry() return CodeT,
- makes Execution::CallWasm() accept CodeT.
Bug: v8:11880
Change-Id: Ic4b7b5f476c6efcfca4bc116ecd45cdee9f0c6c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2971743
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75247}
The {WasmCodeManager::CanRegisterUnwindInfoForNonABICompliantCodeRange}
method does not access any information on the {WasmCodeManager} object,
hence make it static.
R=jkummerow@chromium.org
Bug: v8:11879
Change-Id: I9a06ec556825bc7709970b65f22156952fa7f191
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972726
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75246}
When result is returned in a register to the calling code, some GCC
versions use 32 bit compare, and some use 64 bit compare. In the case
comparison is 64 bit, GCC on PPC64 arch is expecting the return value to
be sign-extended, leading to an error in comparison.
Change-Id: I05b7e1566bc9bb931ce9998bb310eb29c50e90e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968449
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Vasili Skurydzin <vasili.skurydzin@ibm.com>
Cr-Commit-Position: refs/heads/master@{#75245}
To try and reduce StringBuilder's dependencies, use std::memcpy instead
of the V8-only MemCopy.
Change-Id: I576dccd4a2ff1b796314f8e806cbb0c70f6c07f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972730
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75244}
The adding of base:: was mostly prepared using git grep and sed:
git grep -l <pattern> | grep -v base/vector.h | \
xargs sed -i 's/\b<pattern>\b/base::<pattern>/
with lots of manual clean-ups due to the resulting
v8::internal::base::Vectors.
#includes were fixed using:
git grep -l "src/utils/vector.h" | \
axargs sed -i 's!src/utils/vector.h!src/base/vector.h!'
Bug: v8:11879
Change-Id: I3e6d622987fee4478089c40539724c19735bd625
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968412
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75243}
We were gating baseline compilation on FBV allocation, but in some
cases, the feedback vector may be allocated eagerly (notably, if we are
logging function events). Instead, unconditionally try baseline
compilation after ensuring the feedback vector exists.
Bug: v8:11420
Change-Id: I1264a1d541a74d4eccb5caf65c360ac23836a1a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953161
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75242}
After the last CL on TSAN support for generated loads, we are seeing
timeouts in one of our TSAN bots.
Bug: v8:7790, v8:11600
Change-Id: I90924540c5ddcf9902f936849df28aff0f7bd3d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972724
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75241}
Bug: v8:11880
Change-Id: Ia86bab21851e8ff2f2317495a9f0e19140b0de2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2969827
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75240}
This CL migrates BaselineData::baseline_code field and
InterpreterData::interpreter_trampoline field to CodeT.
Bug: v8:11880
Change-Id: Ibd202f0dcd4266e5b98aa5c46754ba8a4fadff43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968415
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75233}
Currently, we have two different classes for switching the WebAssembly
generated code space to writable (e.g., before patching jump tables, or
when adding or removing code): `CodeSpaceWriteScope` (with the macro
`CODE_SPACE_WRITE_SCOPE`) and `NativeModuleModificationScope`.
The former was introduced for Apple Silicon ARM64 hardware ("Apple M1"),
which uses `MAP_JIT` + `pthread_jit_write_protect_np()` to change memory
permissions. The latter uses either Intel PKU (aka. memory protection
keys) to switch permissions (fast and thread-local, like on M1), and
alternatively `mprotect()`, on systems that do not have PKU support.
Since both classes serve the same purpose just with different
implementations on different platforms, we want to merge them in
follow-up CLs. As a first step, here we align all uses of
`CODE_SPACE_WRITE_SCOPE` with existing `NativeModuleModificationScope`s.
The two had diverged due to optimization work, where we moved
`NativeModuleModificationScope`s around (pulling them out of loops and
across function boundaries) to lower the amount of mprotect switches.
This should have none, or at best a very small positive performance
impact on Apple M1, since we now also switch less often (even though
switching should be very cheap). In terms of security, this in theory
makes the code space writable for longer time spans, but this is
probably not a large effect because
(1) we often moved the scope outside of loops, where it was open for
every iteration anyway, or
(2) in some cases a CODE_SPACE_WRITE_SCOPE was open somewhere on the
call stack already.
R=jkummerow@chromium.orgCC=clemensb@chromium.org
Bug: v8:11714
Change-Id: Id8744429e1183e118ab5e078750d294a99c9dce0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968946
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Cr-Commit-Position: refs/heads/master@{#75230}
