The callback IsolateData::ModuleResolveCallback, used by the fuzzer,
can return an empty MaybeLocal.
In this case v8::internal::SourceTextModule::PrepareInstantiate expects
it to have thrown an exception, and DCHECKs.
The fuzzer can hit this case because it doesn't load the entire module
graph before starting to tell V8 to instantiate modules. So if a module
fails to compile or load, another module trying to import it will hit
this DCHECK because we didn't bail out prior to module instantiation
like we should have.
This doesn't happen in Chromium because Blink loads the entire module
graph before trying to instantiate/link modules, ensuring that the
'real' ModuleRecord::ResolveModuleCallback never fails; indeed this is
mandated by the spec (see
https://html.spec.whatwg.org/#fetch-the-descendants-of-and-link-a-module-script).
To satisfy the fuzzer, this change makes
IsolateData::ModuleResolveCallback throw if it can't find the module.
Note, the bug's testcase doesn't involve import assertions. I don't
think this issue is new with my change
9d72d08a8c
but maybe that changed the crash stack or something in a way that
caused the issue to be reported.
Bug: chromium:1207078
Change-Id: I1fbc80faa099e040cdc489c965a5f2f5daafb38e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2890589
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74526}
Reads from the compiler thread require either 1. the last write to
happen before the compiler thread starts, or 2. acquire-release
semantics. For simplicity, this CL converts all NativeContext field
writes to be acq-rel. With the usual exception of writes from
generated code (these are limited for NativeContexts though).
The situation of context sets/gets is still somewhat complex:
- Context::get/set are relaxed (but don't use the corresponding tag)
- Context::get(.., kAcquireLoad) and Context::set(.., kReleaseStore)
are acquire-release.
- Context::set_foo (defined for all native context fields) uses
kReleaseStore underneath.
- Context::get_foo (defined for all native context fields) uses
the default relaxed getter. The get_foo(kAcquireLoad) variant uses
the acquire getter.
- NativeContext hides the default relaxed setter since all
NativeContext sets should be acq-rel.
Ideally (future work), this should be simplified and made more explicit.
For example, get/set_foo could move to the NativeContext class, and we
could reevaluate whether we really need both relaxed and acq-rel
semantics (the pairing non-atomic/acq-rel feels more natural lets
tsan find concurrency issues).
Bug: v8:7790
Change-Id: I25efd37ece758da5a11dc11c6ae913e4975f4d20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891575
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74524}
The HeapProfiler.startSampling method accepts a samplingInterval
parameter, which is assumed to be a positive (non-zero) number,
but doesn't validate the input (the renderer process just crashes
hard on a CHECK instead).
Fixed: chromium:1197392
Change-Id: Ib8e34f4b9881cd195214791ca0a3892e7b49bf55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891573
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74523}
Also delete undefined ContextRef methods and make
Context::set_previous private (it is only used when
creating a new context).
Bug: v8:7790
Change-Id: I25a701f317f0f4e82432f7537eec1d63c5ef63f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2886860
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74521}
Marking on allocation was missing the top level scope.
Also adding a dedicated scope for on allocation to more clearly
distinguish it in traces.
Bug: chromium:1056170
Change-Id: I1b7d80c9f171f81988826de0174ef5b00d6f1d34
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891572
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74520}
This CL enhances the fast C API in a way to allow passing the receiver
to the fast callback as Local<Object> instead of Local<Value>. It also
fixes documentation comments.
Bug: chromium:1052746
Change-Id: I424aa83023c2e6633b9df08ee040bf170db32b3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2887510
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74519}
We just asked if saves_fp was different than 0 two lines above.
Change-Id: I8cca5206041d3436ac7b2d619ab82f5955e99aaf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2888285
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74518}
The WebAssembly specification requires the "name" property of (exported)
function wrappers to hold the index of the function within the module,
and the default ToString algorithm for Function instances thus generates
something along the lines of `function 42() { [native code] }`, which is
technically correct, but not very useful to developers to diagnose
(humans don't think of functions in a module in terms of their indices).
With this CL, we change the description returned for Wasm (exported)
functions to use the debug name of the Wasm function instead.
Screenshot: https://imgur.com/a/FVPeXDU.png
Doc: http://bit.ly/devtools-wasm-entities
Fixed: chromium:1206620
Bug: chromium:1164241
Change-Id: I096abc287ea077556c13c71f8d71f64452ab4831
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891570
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74517}
Drive-by-fix: Remove command line API fn.toString() override, which was
still in place from the early days when much of the inspector was
implemented in JavaScript.
Fixed: chromium:1207867
Bug: chromium:1206620
Change-Id: I8429f109da5f021f729f184fd824160a24e60897
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2887508
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74516}
This reverts commit 0ce36e7d0e.
Reason for revert: Speculative revert for a Chromium build breakage causing a blocked roll - https://bugs.chromium.org/p/v8/issues/detail?id=11761
Original change's description:
> [ic] Fix handling of API properties with side effects
>
> DebugEvaluate can evaluate expressions in side-effect-free mode, where
> any operation that would cause observable side effects throws an
> exception. Currently, when accessors are backed by callbacks, it's
> possible that ICs call those accessors directly, bypassing the
> side-effect checks. This CL introduces a bailouts to runtime in those
> cases.
>
> Fixed: chromium:1201781
> Also-By: ishell@chromium.org, pfaffe@chromium.org
> Change-Id: Ie53bfb2bff7b3420f2b27091e8df6723382cf53c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857634
> Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74507}
Change-Id: Ifb5c24682af29572591d436ab92b0304058e99af
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891650
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@{#74515}
Rolling v8/build: 52ccb29..4e27ee8
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/1fbada9..302ca09
Rolling v8/third_party/depot_tools: c499142..b65bbfe
Rolling v8/third_party/google_benchmark/src: 3b508fa..7d0d906
Rolling v8/tools/clang: e76c8f1..53a9334
Rolling v8/tools/luci-go: git_revision:1b50bbe2f93441dd227ad6e6684fa9be4ab0dec2..git_revision:37e5f238829f911f85b62d66670d2fbd88354ef1
Rolling v8/tools/luci-go: git_revision:1b50bbe2f93441dd227ad6e6684fa9be4ab0dec2..git_revision:37e5f238829f911f85b62d66670d2fbd88354ef1
Rolling v8/tools/luci-go: git_revision:1b50bbe2f93441dd227ad6e6684fa9be4ab0dec2..git_revision:37e5f238829f911f85b62d66670d2fbd88354ef1
TBR=v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: If03b514240069b576a774c574225d84a387b8b7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2888363
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@{#74514}
The following bit casting method using reinterpret_cast
has undefined behaviour:
```
int a = 1;
float b = *reinterpret_cast<float*>(&a);
```
Above breaks the strict aliasing rule which indicates:
> dereferencing pointers to objects of different types will
never refer to the same memory location.
More information can be found under src/base/macros.h.
`bit_cast` here is implemented with `memcpy` behind the scenes.
C++20 will have this feature included by default.
Change-Id: I69ffdbeba6db64e24b268d838ea1d863fcd9121d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2889331
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74513}
On x64 we can emit more compact instructions for mov(reg, imm). However
currently this only happens when using the Set method explicitly.
This CL renames Set to Move to avoid confusion and yield better code
by default.
Also use the new Move helper for Smis as well.
Change-Id: I06558e88d1142098f77fb98870f09742d494f3dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874450
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74512}
Allow GC of the shared heap without any attached clients. This
CL also disables incremental marking for shared heaps for now.
Bug: v8:11708
Change-Id: I1eb47a42fe3ced0f23f679ecaae0c32e09eab461
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2886878
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74511}
This change adds support for `const` redeclaration on REPL mode with
the semantincs recommended in the design doc:
1) REPL scripts should not be able to reassign bindings to `const`
variables.
2) Re-declaring `const` variables of page scripts is not allowed in
REPL scripts.
3) Re-declearing `const` variables is not allowed in the same REPL
script.
4) `const` re-declaration is allowed across separate REPL scripts.
5) Old references to previously declared variables get updated with the
new value, even those references from within optimized functions.
Design doc: https://goo.gle/devtools-const-repl
Bug: chromium:1076427
Change-Id: Ic73d2ae7fcfbfc1f5b58f61e0c3c69e9c4d85d77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2865721
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74510}
DebugEvaluate can evaluate expressions in side-effect-free mode, where
any operation that would cause observable side effects throws an
exception. Currently, when accessors are backed by callbacks, it's
possible that ICs call those accessors directly, bypassing the
side-effect checks. This CL introduces a bailouts to runtime in those
cases.
Fixed: chromium:1201781
Also-By: ishell@chromium.org, pfaffe@chromium.org
Change-Id: Ie53bfb2bff7b3420f2b27091e8df6723382cf53c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857634
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74507}
The deoptimization table needs to be continuously, so we need to block
trampoline pool emission during the whole process.
bug: v8:11759
Change-Id: Ie5e0ffe27dc8e6cdb18985dc2cf26bdadeff318f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2881918
Commit-Queue: Junliang Yan <junyan@redhat.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74506}
Argc and Slot are usually small and fit within a single 32bit word.
This reduces most property calls by 5 bytes.
This results in roughly 1% code reduction for sparkplug and no
measurable regression on x64.
Bug: v8:11420
Change-Id: I272c26c40b99f2dc5817f18bec113662a5bfebce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2872828
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74505}
This is the second CL in a line of two to implement PKU-based
WebAssembly code space write protection. The first CL added two
low-level PKU functions; this CL uses them to grant/withdraw writable
permissions, local to each thread that wants to modify the code space.
In particular, when {--wasm-memory-protection-keys} is enabled, we first
associate a memory protection key with all code pages, which by
default does not allow any write access. Then, before each location that
needs to modify the code space, we open
{NativeModuleModificationScope}s (which are already present for
mprotect-based write protection). When the PKU flag is given, this then
first tries to set permissions of a memory protection key (which is
fast), and otherwise when {--wasm-write-protect-code-memory} is enabled,
falls back to mprotect-based write protection (which is much more
expensive and also not thread-local, but for the whole process).
R=clemensb@chromium.org
Bug: v8:11714
Change-Id: I3527906a8d9f776ed44c8d5db52539e78e1c52fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2882800
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74501}
This is the first CL in a line of two to finish PKU-based WebAssembly
code space write protection. This CL adds two low-level PKU functions,
which are essentially wrapping the functionality in glibc's
{pkey_mprotect()} and {pkey_set()}).
The added functionality is in
(1) {SetPermissionsAndMemoryProtectionKey()}: Associate a memory
protection key with a page (simultaneously with setting the page's
regular permssions). This is as costly as a regular {mprotect()}.
This call itself does not restrict permissions besides the regular page
permissions.
(2) {SetPermissionsForMemoryProtectionKey()}: Set permissions for the
key itself (now associated with a page). This can be either "all data
access disabled" (i.e., no read or write, but execution is allowed) or
"write access disabled" (which we use for code space write protection).
The permissions are added on top of the page's regular permissions. This
operation is cheap (in the order of 20 cycles) since it is roughly a
thread-local register read, some bit-masking, and register write.
See the second CL (based on this one) for how those two functions will
be used.
A note on compatability and security implications: Because the functions
which we use here were only added in glibc 2.27, and since glibc is
dynamically linked, we check at runtime (with {dlsym()}) whether
{pkey_*()} functions are available. However, calling functions via a
pointer coming from {dlsym()} is not supported by CFI so far, which is
why we disable indirect call checking for the added functions.
Potentially, the functions could hence be used as an indirect call
gadget in a ROP attack. On the other hand, they are only compiled in
currently only on Linux on x64, and disabling CFI indirect call checking
is also done in other places already.
R=clemensb@chromium.org
Bug: v8:11714
Change-Id: I0da00818f28cf1da195a5149bf11fccf87c5f8ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2882797
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74498}
Member is sometimes still used from off-heap storage which prohibits
getting the heap from the Member's slot address.
Bug: v8:11756
Change-Id: I61658ce07a8b02a8c400232ff21c75f0d8b95dcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2886879
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74496}
Isolate::UseAsSharedIsolate() was invoked after the Isolate was already
created. I think it is cleaner to have the shared-flag right when
constructing an Isolate. This way we can use that property already
when setting up the isolate.
Bug: v8:11708
Change-Id: Ibbfee09122b7b0361a5af7a1b559796594834813
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2885041
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74495}
It was never stored with a release store, so can we use the loads as
non-atomic ones.
Bug: v8:7790
Change-Id: Ife67e8650a5fb279ad808e5e68c2ab46ee3507c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880541
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74493}
Rolling v8/build: f8d7f9d..52ccb29
Rolling v8/third_party/aemu-linux-x64: H-kH9WxQErL_AR-Nu_ZL8hbu1D-rZmdQQUaYZYm3AOUC..pwjSs3IapHTvM0wB7z3723g8rjsQnCWikZJhQxtBetsC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/c92267a..1fbada9
Rolling v8/third_party/depot_tools: 03dfb00..c499142
Rolling v8/third_party/google_benchmark/src: 0852c79..3b508fa
Rolling v8/third_party/zlib: eb9ce8c..618ddec
Rolling v8/tools/clang: dbcffda..e76c8f1
Rolling v8/tools/luci-go: git_revision:66f9c8541b85c7f6efc63e75e68d660d4fb30752..git_revision:1b50bbe2f93441dd227ad6e6684fa9be4ab0dec2
Rolling v8/tools/luci-go: git_revision:66f9c8541b85c7f6efc63e75e68d660d4fb30752..git_revision:1b50bbe2f93441dd227ad6e6684fa9be4ab0dec2
Rolling v8/tools/luci-go: git_revision:66f9c8541b85c7f6efc63e75e68d660d4fb30752..git_revision:1b50bbe2f93441dd227ad6e6684fa9be4ab0dec2
TBR=v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: I7c116cf19efaf2f55a7b40070a47645eb725c8d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2886659
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@{#74492}
- Share RemeberedSetAction and SmiCheck enums between all platforms.
- Convert to enum classes with k-prefixed values
Bug: v8:11420
Change-Id: Ib265a229f12a850ea866fd01d8022cbae5e1a9d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2885040
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74489}
After updating our bots to use GCC 7.4, we do not need to support
incomplete C++14 support any more. In particular, we can assume
complete c++14 constexpr support now.
This CL removes the V8_HAS_CXX14_CONSTEXPR and CONSTEXPR_DCHECK macros.
The CONSTEXPR_DCHECKs are replaced by DCHECK and friend, or
STATIC_ASSERT where possible.
R=jgruber@chromium.org, leszeks@chromium.org, mlippautz@chromium.org
Bug: v8:9686, v8:11384
Change-Id: I3a8769a0f54da7eb2cacc37ee23e5c97092e3051
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876847
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74486}
The AtomicWeak wscope was nested within the AtomicMark scope. Both
should be top level scopes and should be nested within each other.
Bug: chromium:1056170
Change-Id: I1d695c1a3a24fff31aa57893739dca4b558901fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2883663
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74485}
This reverts commit 5f0ac36cc6.
Reason for revert: Seems to be associated with multiple Sanitizer failures:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/3176
Original change's description:
> [compiler] Consider IsPendingAllocation in Ref construction
>
> The logic in JSHeapBroker::TryGetOrCreateData assumes that parts
> of the object are safe to read. In particular, the instance type
> must be readable for the chain of `Is##Name()` type checks.
>
> This is guaranteed if
>
> - a global memory fence happened after object initialization and
> prior to the read by the compiler; or
> - the object was published through a release store and read through
> an acquire read.
>
> The former is protected by the new call to ObjectMayBeUninitialized
> (which internally calls IsPendingAllocation) in TryGetOrCreateData.
>
> The latter must be marked explicitly by calling the new
> MakeRefAssumeMemoryFence variant.
>
> Note that support in this CL is expected to be incomplete and will
> have to be extended in the future as more cases show up in which
> MakeRef calls must be converted to MakeRefAssumeMemoryFence or to
> TryMakeRef.
>
> Bug: v8:7790,v8:11711
> Change-Id: Ic2f7d9fc46e4bfc3f6bbe42816f73fc5ec174337
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874663
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74474}
Bug: v8:7790
Bug: v8:11711
Change-Id: Ia736cd1143da30ca25fdc2c3c1a2056ebf18d596
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2883245
Auto-Submit: Bill Budge <bbudge@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@{#74484}
This was missing from Ulan's implementation for
CollectCustomSpaceStatisticsAtLastGC.
Bug: chromium:1056170, chromium:1181269
Change-Id: I72354e4f04873095eac5cb39ed188ed83de0bd26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880219
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74483}
The FrameSummary::FunctionName() method is only used by the
FrameInspector in the debugger, so the natural place to put
the dependency on GetWasmFunctionDebugName() is in there,
rather than adding a new dependency to frames.cc. This is a
follow up cleanup as discussed in https://crrev.com/c/2878734
Bug: chromium:1159307
Change-Id: I0698adf63f88fe6a93d6e5e6235bc0c2219e9341
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2883784
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74482}
As a first step to support Fast API calls with overloads, adds a
new FunctionTemplate constructor that accepts a vector of CFunction*.
Bug: v8:11739
Change-Id: I112b1746768f52df52c893a4f1fb799b6bd90856
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2860838
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74481}
Disable the checksum comparison for the read-only snapshot when
--stress-snapshot is used, since it's possible that it would be
corrupted. This corruption is not important as the purpose of
stress-snapshot is not to produce a useable snapshot, but to test that
the serialization/deserialization does not fail for any given objects.
Since the --stress-snapshot flag's value is now used outside of d8,
this also moves it to flag-definitions.h.
Cq-Include-Trybots: luci.v8.try:v8_linux64_gc_stress_custom_snapshot_dbg_ng
Bug: v8:11750
Change-Id: Iedcf1cfb5afa5f16ac19a76820b62b5b93948f2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2882810
Commit-Queue: Dan Elphick <delphick@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74480}
Make %PretenureAllocationSite more resilient to fuzzer inputs/configs
and allow it for fuzzing.
Bug: chromium:1200724
Change-Id: I541b1410ab1719b478c4ad9516dc350fec02fbba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2883783
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74479}
This is a partial reland of https://crrev.com/c/2850932, which was
reverted because the histogram failed Chromium integration. The V8
histogram added here uses only two values (0 = no support, 1 = support),
but is declared with 3 buckets in order not not fail a DCHECK on
Chromium's side. As soon as https://crrev.com/c/2874651 lands in
Chromium, we can properly declare the histogram here with only 2 buckets,
but for now this is good enough to get early data on PKU support in
the wild.
The other part of the original reverted CL (adding PKU alloc and free
functions, and a V8 flag for PKU) was already landed again in
https://crrev.com/c/2878738
Original change's description:
> [wasm] Add PKU alloc/free and support counter
>
> To enforce W^X for the WebAssembly code space, we want to explore using
> Intel memory protection keys for userspace, also known as MPK, PKEYs, or
> PKU. Instead of flipping page protection flags with mprotect (which
> incurs a high syscall overhead; and which switches flags for the whole
> process), this associates a key with each page once, and then changes
> the permissions of that key with a fast thread-local register write.
> That is, this gives both finger-grained permissions (per-thread) and
> more performance.
>
> This CL is starts experimenting with PKUs by
> (1) trying to allocate a protection key once per {WasmEngine} in x64
> Linux systems, and
> (2) adding a counter for recording the sucess/failure of that, to assess
> the support for PKUs on the target machine.
>
> The low-level PKU allocating functions should be moved into base/platform
> long-term, but are inside wasm/ for this CL.
>
> R=clemensb@chromium.org
> CC=jkummerow@chromium.org
>
> Bug: v8:11714
> Change-Id: Ia4858970ced4d0b84cc8c2651e86dceb532c88a7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850932
> Commit-Queue: Daniel Lehmann <dlehmann@google.com>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74319}
Bug: v8:11714, chromium:1207318
Change-Id: I1035ac09bd7aa04584fbc5df7a408b96dd270d0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2871451
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Cr-Commit-Position: refs/heads/master@{#74477}
