Following change in https://github.com/WebAssembly/stringref/pull/22.
This adds two new parsing modes: a strict UTF-8 parsing mode, and a
sloppy mode that should replace invalid subsequences with U+FFFD.
Bug: v8:12868
Change-Id: I03bd8d2a3408c399ce68f7b150d7650908804113
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3719919
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andy Wingo <wingo@igalia.com>
Cr-Commit-Position: refs/heads/main@{#81337}
In the case of bugs creating shared->local edges, this lets us catch
dangling pointers via CHECKs before they happen.
Also removed some redundant checks in the shared struct verifier.
Existing heap verification already checks that all of a Heap's pointers
are contained within it.
Bug: v8:12547
Change-Id: Ic7a007b3b6559e3dfd0286fbf869586023c6f801
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3704911
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81335}
SeqStrings have their padding bytes serialized as 0s for deterministic
snapshot contents. Currently this is done by mutating the SeqStrings and
memsetting their padding bytes to 0 when serializing. This mutation is
not threadsafe in the presence of shared strings. This CL removes the
mutation by serializing the data and padding payloads separately for
SeqStrings.
Bug: v8:12939
Change-Id: I58c3ada767ce41e0a874a2d6e6392a86142fa1e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3715715
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81334}
This will allow us to more easily add a strict UTF-8 decoder, for use in
stringrefs.
Bug: v8:12868
Change-Id: I6835dca619417f4d2994d8283728cf8ebe599bd7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714660
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Andy Wingo <wingo@igalia.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81333}
This reverts commit 543acf345a.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release/10365/overview
Original change's description:
> cppgc: Minor fix in cppgc efficiency calculation
>
> Efficiency calculation (freed bytes over GC duration) assumes that the
> duration of the GC is non zero. However, if the clock resolution is
> not small enough and the entire GC is very short, the timed value
> appears to be zero. This leads to NaN values showing in metrics and
> CHECKs failing. This CL fixes the issue.
>
> Bug: chromium:1338256
> Change-Id: I1dbc52072fcde3411aa38fa0c11da25afd107ca8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714356
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81329}
Bug: chromium:1338256
Change-Id: Ie9a23651494fc28a11bb59485a9812ee1a7cff48
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3721697
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#81331}
Code for map methods was added a really long time ago but no one ever
brought that to set. Adds new common lowering for both collections and
updates the SetPrototypeHas builtin. My initial testing shows this to
be as much as 50x faster in some cases.
Change-Id: Ifea5be01c9e51013d57ac00bd817759ceace6669
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3709246
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: snek <snek@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81330}
Efficiency calculation (freed bytes over GC duration) assumes that the
duration of the GC is non zero. However, if the clock resolution is
not small enough and the entire GC is very short, the timed value
appears to be zero. This leads to NaN values showing in metrics and
CHECKs failing. This CL fixes the issue.
Bug: chromium:1338256
Change-Id: I1dbc52072fcde3411aa38fa0c11da25afd107ca8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714356
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81329}
Port e35039e773
Original Commit Message:
If the returned promise rejects, we switch to the suspender's stack and
throw the value.
Re-purpose the WasmOnFulfilled data to also represent the rejecting
case and rename it to WasmResumeData.
R=thibaudm@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: Ic9e5b959df90f1041353662dc054a849fea9874e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3721416
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#81328}
Throw a wasm trap when trying to re-enter a suspender that is active or
suspended.
R=ahaas@chromium.org
Bug: v8:12191
Change-Id: Ic448a15db29de14fb8d6bb8408af8fbaae82a2b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716481
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81326}
If the returned promise rejects, we switch to the suspender's stack and
throw the value.
Re-purpose the WasmOnFulfilled data to also represent the rejecting
case and rename it to WasmResumeData.
R=ahaas@chromium.orgCC=fgm@chromium.org
Bug: v8:12191
Change-Id: I91a301c3c6d9d243efbfabe7263555e11f0d9277
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3706606
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81325}
To be able to share external strings, we need to share the external
pointer table in sandbox builds.
To avoid branches at runtime all pointers for external strings are
stored in the shared external pointer table.
Bug: v8:12957
Change-Id: Iaa6be7839a2f5e50f80fd58c5b33fb9c6af61057
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695263
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81324}
MinorMC events were incorrectly grouped under the V8.GCScavenger trace event name.
This CL introduces the trace event name V8.GCMinorMC and uses it when MinorMC is used instead of Scavenger.
Change-Id: Ide22526adfa9cc6dec91d3c34186b1c2ea6eb862
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717989
Commit-Queue: Leon Bettscheider <bettscheider@google.com>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81323}
TrapIf and TrapUnless had an effect input, but not an effect output.
This is not canonical for Turbofan graphs. This CL puts them properly
into the effect chain.
Drive-by:
- Remove premature optimization in WasmGraphBuilder::TrapIfEq{32,64}.
- Change LoadFromObject to Load when loading from a stack slot.
Change-Id: I3fc43e693fa0507406dc31208e487026b0e5156b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714240
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81318}
A lot of logic is missing from the Wasm entry for fast api calls.
The majority of the lowering is shared between wasm and js, and uses
the same graph operators, so this adds a common fast api call builder
which can be called from the wasm compiler and the js compiler.
Bug: chromium:1052746
Change-Id: I9dbd82548951b2b155a7b2459714239d0b251d71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3708842
Commit-Queue: snek <snek@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81315}
Changes for TF instruction selector will be pasted
in the CL comments and will get applied once all
relaxed opcodes have been implemented in codegen/liftoff.
Change-Id: I231aa6fcc702a19704b7707331eba549c44232d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3718393
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#81313}
With recent changes, we resolve the promise of e.g. WebAssembly.compile
with the external API, and not the V8-internal API. The external API,
however, also handles microtasks, and depending on the MicrotasksPolicy,
may also execute microtasks immediately. This means the then-handler of
WebAssembly.compile may get executed within all the scopes that were
open when the external API was called. One of the open scopes is the
CancelableTask that finishes WebAssembly compilation.
The deadlock seen in the issue arises now when {quit()} gets called in
the then-handler of WebAssembly compilation. The reason is that
{quit()} terminates the isolate, and during isolate termination, we wait
for all running CancelableTasks to finish. This, however, means a
deadlock, because the task that terminates the isolate is waiting for
itself to finish.
R=jkummerow@chrommium.org
Bug: chromium:1338150
Change-Id: I89243daffc76a456293519e24bfaad88277bb99a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717990
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81311}
SourceTextModule::ExecuteAsyncModule asserts the execution of
the module's async function to succeed without exception. However,
the problem is that TerminateExecution initiated by embedders is
breaking that assumption. The execution can be terminated with an
exception and the exception is not catchable by JavaScript.
The uncatchable exceptions during the async module evaluation need
to be raised to the embedder and not crash the process if possible.
Refs: https://github.com/nodejs/node/issues/43182
Change-Id: Ifc152428b95945b6b49a2f70ba35018cfc0ce40b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3696493
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Chengzhong Wu <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#81307}
There seems to be a bug in gcc which causes link errors after
this CL: https://crrev.com/c/3714238
Issue seems to happen when using default template argument
of function type. A related bug report on bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105848
A workaround is to explicitly instantiate the template
for type <bool>.
Bug: v8:12991
Change-Id: I74db7d42d7b41e8af5d721b8c10130a7a0f2a999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3718379
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81304}
- Check that internalized strings always have a computed hash value.
- Check that ThinStrings never have a forwarding index.
- Add a simple test of various property access with
--always-use-string-forwarding-table to make the CF aware of the flag.
Change-Id: Ie047c9f635d5e0ed999208ec3379ef09c395b3f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717988
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81303}
Part 1:
Revert "PPC: skip slow tests on the ppc simulator"
This reverts commit 9dfac00a1d.
Part 2:
Make the slow test faster.
Bug: v8:11111
Change-Id: I8f0291098d29917fa65c4b5b28bf03cbdbe7ebc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714229
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81301}
If parsing fails in ScopeIterator::TryParseAndRetrieveScopes, the
intention was to fail silently (see the TODO there). However,
closure_scope_ being nullptr caused us to fail less silently.
This alone is not enough for fixing chromium:1316811 but the other
fixes needed are sufficiently unrelated.
Bug: chromium:1316811
Change-Id: I4eb0f5a13fa4da5fd5dd7ff76a1aa1a6a8ee4c63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716477
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81300}
Recently perfetto introduced `perfetto::DynamicString` to allow clients
to wrap dynamic event name strings. So that clients don't have to
manually set event name inside trace lambda.
With that:
TRACE_EVENT("cat", nullptr, [&](EventContext ctx) {
ctx.event().set_name(dynamic_name_str)
});
is simplified to:
TRACE_EVENT("cat", perfetto::DynamicString{dynamic_name_str});
In this change we are making use of perfetto::DynamicString to pass
dynamic event name string.
Change-Id: Ic6b501df67409d6faa4d60b59095ad0e79ce585e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716473
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Mohit Saini <mohitms@google.com>
Cr-Commit-Position: refs/heads/main@{#81298}
When the sandbox is enabled, an empty ArrayBuffer does not have a
nullptr backing store but instead points to a special EmptyBackingStore
pseudo-object inside the sandbox. This then requires special handling
during deserialization. This CL fixes two cases where this was not done
correctly, which caused some crashes when --stress-snapshot is active.
Bug: v8:10391
Change-Id: I412adace229b979b317864a3e8c12ed4c601b850
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716480
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81297}
This CL introduces a compile flag v8_enable_inner_pointer_resolution_osb
behind which lies the experimental implementation of the object start
bitmap. It disassociates the object start bitmap from the compile flag
v8_enable_conservative_stack_scanning. At the moment the former flag is
a prerequisite for the latter, as conservative stack scanning requires
some mechanism for inner pointer resolution and the object start bitmap
provides one such mechanism.
Bug: v8:12851
Change-Id: I24c6b389453fbaefc79ae50c34c5ec7a1bf23347
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717322
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81295}
This should not be necessary, but something was failing previously
when removed. Now that we have the blocklist just merging once seems
to work.
Bug: v8:7700
Change-Id: I6534506263ae739f28043eef2dee7aba8f28eadf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717983
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81294}
Check against copying around a TracedReference containing a zap value.
Bug: chromium:1322114
Change-Id: Ie97ecaf18931006516fc70be262829a267d1285c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717323
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81293}
When a GC was requested via stack guard, we don't restart incremental
marking anymore on finding new objects but rather finish the GC cycle.
This regressed in https://crrev.com/c/3702801
Bug: v8:12985, chromium:1338071, v8:12775
Change-Id: Ie515cea6d5345ad1111a4fb9f042cffc52083453
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716486
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81291}
Bug: v8:12978
Change-Id: Ic8c73eafbd080714915268c8bcb9f2c30614b9b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3711712
Auto-Submit: Adam Klein <adamk@chromium.org>
Reviewed-by: Frank Tang <ftang@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81288}
