...in Runtime_StringToArray.
When a string is sliced from an externalized two-byte string that has
only one-byte chars, String::IsFlat() and
should not call ToOneByteVector() on it and instead we should use
String: :IsOneByteRepresentation() can both be true, while
FlatContent: :IsOneByte() returns false. In this case we
String: :Get() to get the individual characters.
Bug: chromium:1350270
Change-Id: I735408602072279f09b32e1997c97b2900942bdd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3813070
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#82268}
This change removes the subtyping between funcref and anyref.
Currently, nullref (ref null none) is still a subtype of funcref and externref.
This has to be adapted in a follow-up change introducing nullexternref
(ref null noextern) and nullfuncref (ref null nofunc).
Bug: v8:7748
Change-Id: I77a1b3fef387faf710f7bf7bf9d4655fb600ffdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804253
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82267}
Add a --deopt-to-baseline flag, on by default, which allows returning to
sparkplug code when deoptimizing.
However when we turn this off, no longer deoptimizing to baseline code
means we can omit marking most bytecodes as valid jump targets. Leaving
just OSR and exception handling entry points.
This reduces the baseline code size by ~18% on Arm64.
Bug: v8:13082
Change-Id: I5b5a6679465807d7fe812cb977464167efffa7ab
Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_cfi_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785006
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/main@{#82266}
... - a code range size agnostic version of InterpreterEntryTrampoline
builtin. The new builtin is fully compatible with the default version
and used as a template for creating interpreter entry trampoline
Code objects when --interpreted-frames-native-stack is enabled.
This CL introduces a new assembler option "position_independent_code"
which affects the way builtin calls are generated.
This mode is enabled only for InterpreterEntryTrampolineForProfiling.
Motivation:
* InterpreterEntryTrampoline uses RelocInfo::CODE_TARGET for calling
other builtins which requires the code range to be small enough to
allow PC-relative jumps/calls between Code objects. This is the
reason why --interpreted-frames-native-stack was not supported on
arm and might not work on arm64 because the code range is bigger
than the max PC-relative distance for call/jump instructions.
The new builtin calls other builtins via builtins entry table which
makes the code fully relocatable and usable for any code range size.
* RelocInfo::CODE_TARGET requires a target code to be materialized
as a Code object which contradicts the Code-less builtins goal.
* The --interpreted-frames-native-stack is rarely used in the wild but
we have to pay the price of deserializing InterpreterEntryTrampoline
builtin as a Code object which consumes address space in the code
range and thus limits the number of V8 isolates that can be created
because of code range exhaustion. Now the pointer compression cage
becomes the limiting factor instead of the code range.
* We can remove complicated logic of Factory::CopyCode() and respective
support on GC side.
Bug: v8:11880, v8:8713, v8:12592
Change-Id: Ib72e28c03496c43db42f6fe46622def12e102f31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811287
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82263}
So far there was no support for allocating large objects in the
shared heap.
Bug: v8:11708
Change-Id: Ie4ec8244fee2e75fc0e2265847fe5976da2645ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811579
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82261}
This allows arm64 to produce an extending load from ChangeInt32ToInt64(Load(x)) more frequently.
Reduces embedded code size by 0.66% for arm64.
This change gives 0.3% for Speedometer on an A55 machine.
Change-Id: Ie27a134cea3dfc8a26b87553f27ca01bf9f00f1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3803227
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: George Wort <george.wort@arm.com>
Cr-Commit-Position: refs/heads/main@{#82258}
Many messages already do not end in a ".", which makes sense for
embedders that format location and message in one line, like Chrome.
Before:
V8 error: Empty MaybeLocal. (v8::ToLocalChecked).
After:
V8 error: Empty MaybeLocal (v8::ToLocalChecked).
R=mlippautz@chromium.org
Change-Id: Ibfb226c50ae8dce4057cdf0012e58fa1f27faa2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811586
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82257}
JSTypedArray needs the base_pointer ByteArray immediately
if it's on heap. JSTypedArray's base_pointer was initialized
to Smi::uninitialized_deserialization_value at first when
deserializing, and if base_pointer was deferred, we will
mistakenly check JSTypedArray not on heap.
Bug: v8:13149
Change-Id: I104c83ff9a2017de1c8071a9e116baa602f6977d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3813068
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#82254}
This CL enables Myers algorithm introduced with
https://crrev.com/c/3804860.
Note that Myers finds slightly different diffs in some cases compared
to the current approach so this CL has to rebaseline one test.
R=kimanh@chromium.org
Bug: chromium:1205288
Change-Id: Ife4708a9edf543db938024a5e14c34a589d6a22a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810244
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82247}
This is a reland of commit ccde420538
Added a test case for terminating optimized bigint multiply and attached frame_state to the runtime call to provide deopt information to determine the throw location
Original change's description:
> [TurboFan] Support BigIntMultiply
>
> Bug: v8:9407
> Change-Id: Iab0a4ca8dd5d83444d1addd6043a5c8e3a8577a7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3773773
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82140}
Bug: v8:9407
Change-Id: Ia691d758265148da1de291365d41c7c1d1f98ddd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810391
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82232}
The infrastructure runs everything already in Python3, so this is
mostly a clean-up.
For MB, a python2 holdover was removed and new lint errors were
fixed.
The renames were automated with:
git grep -e "/usr/bin/python$" |
cut -d':' -f1 |
xargs
sed -i 's/#!\/usr\/bin\/python$/#!\/usr\/bin\/python3/1'
and
git grep -e "/usr/bin/env python$" |
cut -d':' -f1 |
xargs
sed -i 's/#!\/usr\/bin\/env python$/#!\/usr\/bin\/env python3/1'
Bug: v8:13148
Change-Id: If4f3c7635e72fa134798d55314ac1aa92ddd01bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811499
Reviewed-by: Liviu Rau <liviurau@google.com>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82231}
This CL fixes a crash when we build the scope chain after re-parsing
for Debugger.evaluateOnCallFrame.
The following script causes the crash:
class A {
test(){
debugger;
}
f = (x) => {}
}
let a = new A()
a.test()
The current scope search tries to be smart and descends deeper
into the scope tree based on source position. That is not a sound
approach as V8 doesn't guarantee that sibling scopes don't overlap.
In the above case V8 creates an instance initializer scope where
f is assigned (and the initializer scope is the parent scope for
the arrow function). The problem is that the initializer scope
uses the same source range as the class `A` itself, so when we
look for the scope for `test`, we descend wrongly into the
initializer scope and can't recover.
The solution is to not try and be too smart:
- First, find the closure scope with a straight-up DFS.
- Once we have that, descend from there and try to find the
closest fitting scope around the break position.
R=bmeurer@chromium.org, jarin@chromium.org
Bug: chromium:1348186
Change-Id: Ic5e20c4d12b3d768f76a17367dc0f87bcc73763b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807594
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82216}
This is a reland of commit 491de34bcc
co-authors: Ji Qiu <qiuji@iscas.ac.cn>
Alvise De Faveri Tron <elvisilde@gmail.com>
Usman Zain <uszain@gmail.com>
Zheng Quan <vitalyankh@gmail.com>
Original change's description:
> [riscv32] Add RISCV32 backend
>
> This very large changeset adds support for RISCV32.
>
> Bug: v8:13025
> Change-Id: Ieacc857131e6620f0fcfd7daa88a0f8d77056aa9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3736732
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
> Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82053}
Bug: v8:13025
Change-Id: I220fae4b8e2679bdc111724e08817b079b373bd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807124
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82198}
v8::TracedReference is supposed to be used from objects allocated on
CppHeap. Such objects can be in construction during garbage
collection, meaning that they are unable to invoke
Trace(v8::TraceReference) as they have not been properly set up.
It is thus necessary to use conservative tracing to find
v8::TracedReference (backed by TracedNode in GlobalHandle) in
in-construction objects.
Change-Id: I5b4ac6e7805ff7ded33f63a405db65ea08d809ad
Bug: v8:13141, chromium:1322114
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3806439
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82188}
Implement the WebAssembly.Function-based API.
With the old API, wrapping an import and export with JS Promise
Integration looked like:
WebAssembly.returnPromiseOnSuspend(<wasm_export>);
WebAssembly.suspendOnReturnedPromise(
new WebAssembly.Function(<sig>, <js_import>));
With the new API:
new WebAssembly.Function(<sig>, <wasm_export>, {promising: 'first'})
new WebAssembly.Function(<sig>, <js_import>, {suspending: 'first'})
For details, see
https://github.com/WebAssembly/js-promise-integration/pull/8/filesR=ahaas@chromium.org
Bug: v8:12191
Change-Id: Iaefaac5304a038fc39283db165b637af7e48b009
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804669
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82183}
With streaming compilation we delay the generation of errors until after
all bytes are received, so that potentially better error messages get
generated. With this CL we also delay the generation of errors in the
combination of lazy compilation and streaming compilation.
In particular, this CL does the following:
* It avoids the creation of a `DecodeFail` task in
`FinishAsyncCompileJobWithError`, which would create an error immediately before a potential name section arrived.
* It calls `CompilationStateImpl::SetError()` so that an error is
created once the stream finishes.
* It removes the return value of `ProcessFunctionBody` so that wire
bytes continue to be received even after a validation error.
* It adds an early exit to `ProcessFunctionBody` if
`CompilationStateImpl::failed()` is true, so that we don't continue
validation after the first detected error.
R=clemensb@chromium.org
Bug: v8:12852
Change-Id: Ie8c6be243a257ef62cbb29fea6b8e0c205060680
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3802691
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82181}
Async compilation with lazy compilation generated an error message that
did not include the function name. With this CL the function name now
gets included.
R=clemensb@chromium.org
Bug: v8:12852
Change-Id: Ia8aed83a2114a2c9da1367045404b20fa8554c8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804863
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82172}
The serialized module contains information for each function whether the
serialized code for the function exists, and whether the function has
been executed before serialization. The latter information is used to
decide if the function should get compiled eagerly after deserialization
(in case the function has been executed before serialization), or if the
function should get compiled lazily because it will probably not be
executed anytime soon.
So far this code only worked for eager compilation. When lazy compilation
was enabled, all functions would get compiled lazily after
deserialization. With this CL the behavior described above is extended to
lazy compilation.
R=clemensb@chromium.org
Bug: v8:12926
Change-Id: Ifd6f400396222105feffa472c2e8787e1358220e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807583
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82171}
This is a reland of commit a1392fa113
The original change was reverted due to v8:13135, which was fixed
separately.
Original change's description:
> Enable background merging when --stress-background-compile
>
> This change adds new functions to BackgroundCompileTask which closely
> match those in BackgroundDeserializeTask. These functions allow a caller
> to manage background merging of newly compiled content into an existing
> Script from the Isolate compilation cache. These functions are not yet
> exposed via the API; instead, StressBackgroundCompileThread uses them to
> increase test coverage of the merging logic.
>
> Bug: v8:12808
> Change-Id: I4d2f429164223785169fe447ce2bdd8beaee00d4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793959
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82121}
Bug: v8:12808
Change-Id: I530c6e87bbad11e178ef4abfdc25fa98530f0224
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3806590
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#82165}
Some tests assume that liftoff code is available immediately after
compilation. Add the `--no-wasm-lazy-compilation` flag to these tests
so that they work even after shipping lazy compilation.
R=clemensb@chromium.org
Bug: v8:12926
Change-Id: I839610221390822b90b25e1bef3ae727fa33d1ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804862
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82162}
This reverts commit a1392fa113.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/43149/overview
Original change's description:
> Enable background merging when --stress-background-compile
>
> This change adds new functions to BackgroundCompileTask which closely
> match those in BackgroundDeserializeTask. These functions allow a caller
> to manage background merging of newly compiled content into an existing
> Script from the Isolate compilation cache. These functions are not yet
> exposed via the API; instead, StressBackgroundCompileThread uses them to
> increase test coverage of the merging logic.
>
> Bug: v8:12808
> Change-Id: I4d2f429164223785169fe447ce2bdd8beaee00d4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793959
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82121}
Bug: v8:12808
Change-Id: Ibb0bc2adb79e4655b39a8a6ac33d8c8ffc5ebdb9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804602
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82137}
This reverts commit 872b7faa32.
Reason for revert: Somewhat speculative revert because of https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/39673/overview (reverting locally resolved the issue for me)
Original change's description:
> Fix Context PromiseHook behaviour with debugger enabled
>
> This is a solution for https://github.com/nodejs/node/issues/43148.
>
> Due to differences in behaviour between code with and without the debugger enabled, some promise lifecycle events were being missed and some extra ones were being added. This change resolves this and verifies the event sequence is consistent between code with and without the debugger.
>
> Change-Id: I3dabf1dceb14233226b1752083d659f1c2f97966
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779922
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82132}
Change-Id: I3e05adead5d8033906055e0741854da68aade2ac
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804859
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82136}
This is a solution for https://github.com/nodejs/node/issues/43148.
Due to differences in behaviour between code with and without the debugger enabled, some promise lifecycle events were being missed and some extra ones were being added. This change resolves this and verifies the event sequence is consistent between code with and without the debugger.
Change-Id: I3dabf1dceb14233226b1752083d659f1c2f97966
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779922
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82132}
This change adds new functions to BackgroundCompileTask which closely
match those in BackgroundDeserializeTask. These functions allow a caller
to manage background merging of newly compiled content into an existing
Script from the Isolate compilation cache. These functions are not yet
exposed via the API; instead, StressBackgroundCompileThread uses them to
increase test coverage of the merging logic.
Bug: v8:12808
Change-Id: I4d2f429164223785169fe447ce2bdd8beaee00d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793959
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82121}
struct.new_default may not be called for immutable structs.
Follow-up to d2c75d321e.
Change-Id: I7b682938ca5da00ef6c9bec29856133301beb6b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3802688
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82108}
Introduce RootVisitor and related class hierarchy to just handle
roots. This avoids the awkard definitions for roots visiation in all
the cases they are not needed.
Change-Id: Ib0912e4bf543db2ecf68caead6929c68d6afdda6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782794
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82107}
Bump the memory size limit of memory64 memories from 4GB to 16GB. Tests
are added for larger sizes (5GB, 16GB).
Drive-by: Improve two decoder errors to properly include the unit,
tested by the new tests.
R=jkummerow@chromium.org
Bug: v8:10949
Change-Id: I99dfc216b9213838784214c0b65ba863831d5884
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789507
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82105}
It's difficult to say which structs might in the future have deprecated
fields, so this CL adds tests for two more for now.
Once we add deprecated fields, we then need to define copy/move
constructs and assignment operators via
{ALLOW_COPY_AND_MOVE_WITH_DEPRECATED_FIELDS} (same as for other structs
which are not tested yet).
R=mlippautz@chromium.org
Bug: v8:13092
Change-Id: I89a330661a02d86d3d48e216b69cb6f77f02cff2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789508
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82098}
This is a reland of commit 07e11a64e4.
The original change removed the fill_thehole_and_call_runtime bailout
in StringBuiltinsAssembler::StringToArray() so when the string
is external and cannot be unpacked, the FixedArray won't be filled
with holes before we call into the runtime, thus failing a
heap verification if a GC happens before the array is filled. This
reland adds back the bailout for this case.
Bug: v8:12718, chromium:1330410
Original change's description:
> [heap] pre-populate the single_character_string_cache
>
> This simplifies the code and removes the runtime overhead of
> spontaneously adding strings to the cache.
>
> Bug: v8:12718
> Change-Id: I2ed49bd82e3baf2563eeb8f463be72c0308c52c5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616553
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#80803}
Change-Id: I25e8724d511a8d0d971fa2a9b6ba8a0eafce4413
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793525
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82082}
If we grow memory (out-of-place, so only without trap handling and only
if the maximum is >1GB) and the previous size is close to the maximum,
then the minimum growth we calculate can be bigger than the allowed
maximum. In this situation, the {std::clamp} has undefined behaviour,
since the provided lower limit is bigger then the upper limit.
Thus apply {std::min} and {std::max} in an order such that {max_pages}
has precedence over {min_growth}.
R=thibaudm@chromium.org
Bug: chromium:1348335
Change-Id: I4f9e9ce10a0685892248eaf0e06ffd2e84b9a069
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793396
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82081}
Due to popular demand.
As a necessary byproduct, this drops our former experimental in-progress
support for accessing struct fields from JS as `.field0` etc. If we need
something similar in the future, we'll have to build a new mechanism for
it that scales to >1020 fields.
Bug: v8:7748
Change-Id: I08b2051bd9f76cf7128f3d4c74910ca891c38130
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793616
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82079}
Call test functions immediately, and make them print their name before
execution.
R=thibaudm@chromium.org
Change-Id: I2057e2b3c2032c342a86705dbda8992aa54493e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793612
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82077}
Table<any> is not allowed any more and may therefore not be generated by
the fuzzer. Instead, the new type is table<externref>.
Bug: chromium:1348437
Change-Id: Ibf788222fc777508e59178db48e6497a18b250d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793610
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82073}
This is required by the MVP spec. In the future, it might be possible
to pass values for any immutable fields.
Bug: v8:7748
Change-Id: Ie7705b48e9d6ebb87d5e1b0a2a10556302395db6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793383
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82072}
Currently, we canonicalize types for call_indirect by looking in the
current module for a signature of the same shape. This is not enough
as of wasm-gc. Instead, the canonical identifier representing a type
has to be computed via isorecursive canonicalization.
This change is implemented behind a flag for now.
Future work: Also integrate export wrappers with isorecursive
canonical types. We need to store wrappers in instance-independent
storage.
Drive-by:
- Always emit type check for call_indirect. We did not emit a check
only when typed-function-references was enabled, but not gc. This
is not something that will be possible long-term.
- Fix some wasm cctests.
Bug: v8:7748
Change-Id: I7cced187009ac148c833dff5e720a8bb9a717e68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784600
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82064}
This very large changeset adds support for RISCV32.
Bug: v8:13025
Change-Id: Ieacc857131e6620f0fcfd7daa88a0f8d77056aa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3736732
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82053}
It was delegating to GetDerivedMap but not handling the possible
error coming from it.
Bug: v8:11111,chromium:1347722
Change-Id: I348ed721281d8edd324f0e364d8ed45602cb9f54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791063
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82046}
This is a reland of commit e895b7af73
The unit test has been updated to work correctly when
--stress-incremental-marking is enabled.
Original change's description:
> Background merging of deserialized scripts
>
> Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
> with which an embedder could request that V8 merge newly deserialized
> script data into an existing Script from the Isolate's compilation
> cache. This change implements those new functions. This functionality is
> still disabled by default due to the flag
> merge_background_deserialized_script_with_compilation_cache.
>
> The goal of this new functionality is to reduce memory usage when
> multiple frames load the same script with a long delay between (long
> enough for the script to have been evicted from Blink's in-memory cache
> and for the top-level SharedFunctionInfo to be flushed). In that case,
> there are two Script objects for the same script: one which was found in
> the Isolate compilation cache (the "old" script), and one which was
> recently deserialized (the "new" script). The new script's object graph
> is essentially standalone: it may point to internalized strings and
> readonly objects such as the empty feedback metadata, but otherwise
> it is unconnected to the rest of the heap. The merging logic takes any
> useful data from the new script's object graph and attaches it into the
> old script's object graph, so that the new Script object and any other
> duplicated objects can be discarded. More specifically:
>
> 1. If the new Script has a SharedFunctionInfo for a particular function
> literal, and the old Script does not, then the old Script is updated
> to refer to the new SharedFunctionInfo.
> 2. If the new Script has a compiled SharedFunctionInfo for a particular
> function literal, and the old Script has an uncompiled
> SharedFunctionInfo, then the old SharedFunctionInfo is updated to
> point to the function_data and feedback_metadata from the new
> SharedFunctionInfo.
> 3. If any used object from the new object graph points to a
> SharedFunctionInfo, where the old object graph contains a matching
> SharedFunctionInfo for the same function literal, then that pointer
> is updated to point to the old SharedFunctionInfo.
>
> The document at [0] includes diagrams showing an example merge on a very
> small script.
>
> Steps 1 and 2 above are pretty simple, but step 3 requires walking a
> possibly large set of objects, so this new API lets the embedder run
> step 3 from a background thread. Steps 1 and 2 are performed later, on
> the main thread.
>
> The next important question is: in what ways can the old script's object
> graph be modified during the background execution of step 3, or during
> the time after step 3 but before steps 1 and 2?
>
> A. SharedFunctionInfos can go from compiled to uncompiled due to
> flushing. This is okay; the worst outcome is that the function would
> need to be compiled again later. Such a risk is already present,
> since V8 doesn't keep IsCompiledScopes for every compiled function in
> a background-deserialized script.
> B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
> compilation. This is also okay; the merge completion logic on the
> main thread will just keep this lazily compiled data rather than
> inserting compiled data from the newly deserialized object graph.
> C. SharedFunctionInfos can be cleared from the Script's weak array if
> they are no longer referenced. This is mostly okay, because any
> SharedFunctionInfo that is needed by the background merge is strongly
> referenced and therefore can't be cleared. The only problem arises if
> the top-level SharedFunctionInfo gets cleared, so the merge task must
> deliberately keep a reference to that one.
> D. SharedFunctionInfos can be created if they are needed due to lazy
> compilation of a parent function. This change is somewhat troublesome
> because it invalidates the background thread's work and requires a
> re-traversal on the main thread to update any pointers that should
> point to this lazily compiled SharedFunctionInfo.
>
> At a high level, this change implements three previously unimplemented
> functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
>
> - BackgroundDeserializeTask::SourceTextAvailable, run on the main
> thread, checks whether there is a matching Script in the Isolate
> compilation cache which doesn't already have a top-level
> SharedFunctionInfo. If so, it saves that Script in a persistent
> handle.
> - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
> whether the persistent handle from the first step exists (a fast
> operation which can be called from any thread).
> - BackgroundDeserializeTask::MergeWithExistingScript, run on a
> background thread, performs step 3 of the merge described above and
> generates lists of persistent data describing how the main thread can
> complete the merge.
> - BackgroundDeserializeTask::Finish is updated to perform the merge
> steps 1 and 2 listed above, as well as a possible re-traversal of the
> graph if required due to newly created SharedFunctionInfos in the old
> Script.
>
> The merge logic has nothing to do with deserialization, and indeed I
> hope to reuse it for background compilation tasks as well, so it is all
> contained within a new class BackgroundMergeTask (in compiler.h,cc). It
> uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
> the object visitation that updates pointers to SharedFunctionInfos.
>
> [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
>
> Bug: v8:12808
> Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#81941}
Bug: v8:12808
Change-Id: Id2036dfa4eba8670cac899773d7a906825fa2c50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787266
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#82045}
Memory64 currently does not use trap handling, so we should not allocate
a guard region (10GB total reservation).
This is implemented by adding a {WasmMemoryFlag} enum in the backing
store header, which replaces the previous {MemoryIndexType}. The flag is
not stored with the backing store, as the backing store does not care
about the index type, and we might want to share the same backing store
for memory32 and memory64 (if sizes permit this).
Instead, we (still) store the flag with the WasmMemoryObject and pass it
to the backing store methods.
R=jkummerow@chromium.org
Bug: v8:10949
Change-Id: I284b85b98d181ba5e8d454b24bfa48f6ac201be5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789506
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82038}
This is a reland of commit 8cb027531c
Original change's description:
> [wasm] Materialize suspender in JS-to-wasm wrapper
>
> Instead of creating the Suspender object in JS and passing it to the
> stack-switching js-to-wasm wrapper, the wrapper now automatically
> creates the Suspender object and forwards it as an extra parameter to
> the wasm function. See:
> https://github.com/WebAssembly/js-promise-integration/pull/1/files
>
> R=ahaas@chromium.org
>
> Bug: v8:12191
> Change-Id: I2badee823f4223a293632f93e7e59f24c49d0820
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779688
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81890}
Bug: v8:12191
Change-Id: Iea233e30aa269279d2fe17f5230c87285c33e232
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780817
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82009}
This CL implements MemoryAllocator::LookupChunkContainingAddress, which
will be used for conservative stack scanning. The method determines
whether an address that may be an inner pointer is contained in some
allocated (normal or large) page. To achieve this, the CL introduces a
page database in the memory allocator.
Bug: v8:12851
Change-Id: I8b719a5f1b6e6b374ccf0666c91c2341c5f9856a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784986
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@{#82004}
The RTT type can not be used directly in WebAssembly any more and is treated
as a compiler-internal type for the GC MVP.
Bug: v8:7748
Change-Id: I97cb241e6c46446149cc6ae2b1d535b93402fa76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787877
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82000}
This is a reland of commit 4e935c7ffb
fix a bug on mac for not return correct memory protection key support.
Please see details in comments.
Original change's description:
> [pku][wasm] Refactor PKU usage in Wasm
>
> RwxMemoryWriteScope becomes the bottleneck for both MAP_JIT and PKU
> machinery.
> Wasm and V8 code space will use the same memory protection key.
>
> This is a next step towards adding PKU support for V8 code space.
>
> Bug: v8:13023
> Change-Id: I647f8c09bc41e5ef8a1d74b58a48a43e08454e0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702213
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81947}
Bug: v8:13023
Change-Id: I5b5cc81e7c1502229ce0d2a5574ca34dc23d19d9
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_rel_ng,v8_mac_arm64_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787320
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81994}
Drive-by-fix:
- Rename baseline to sparkplug for consistency
- Add request timeouts for the local symbol server
- Add script to start a local symbol server
- Fix -h/--help support for linux-perf-chrome-renderer-cmd.sh
Change-Id: I4c2fc3595d672871f20fc5c4065ba45e801a1111
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769699
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81992}
After some solid bike shedding, we decided to rename one part of the
API.
R=jarin@chromium.org
Bug: chromium:1334585
Change-Id: Ie967f9f4947b2c328433e4c4a9d748ad15ae7175
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788095
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81987}
Remove the range check of formatRange, formatRangeToParts on
NumberFormat and selectRange on PluralRules
Bug: v8:10776
Change-Id: Ifede7d61db6414d5b338b22bd188406e5f7d98b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779041
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81984}
Call Intl function which call ICU TimeZone for the calculation
of timezone other than UTC
Bug: v8:11544
Change-Id: Idc355aaeccc0bed026a7117bb366ee914fa29733
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3783074
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81983}
Handle the case where getting a value in the iterable object that
encodes the values throws an exception.
R=ahaas@chromium.org
Bug: chromium:1347073
Change-Id: Ie660ab04148d5fd3508397ae6e08130496f61b74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788097
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81974}
The implicit copy constructor triggers a deprecation warning if the
struct contains a deprecated field. We can fix this by explicitly
declaring the copy and move constructors and assignment operators
with the deprecation warning disabled.
This CL also adds a test to check that we can indeed call the
constructors and assignment operators, which did not work before.
R=leszeks@chromium.org
Bug: v8:13092
Change-Id: Ia63ff9375de13fc6e5b5a8d59d827a742c99fb39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785145
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81962}
This CL refactors the mechanism for testing the implementation of inner
pointer resolution using the marking bitmap. It allows for more than one
page, where objects can be allocated. It also keeps a list of allocated
objects that are automatically tested.
Bug: v8:12851
Change-Id: I470dc1154aca1ebc3d8526872717747829f83396
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784605
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81952}
The intial version of the API was replaced with a more ergonomic one
recently.
We can also safely remove the test as the new API guarantees that
tasks are always finished and cancelled.
Bug: chromium:1334585
Change-Id: I9ff8b92fcd73ef821c86de52c40a1d04b15ea918
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780539
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81950}
This reverts commit 4e935c7ffb.
Reason for revert: Breaking on mac arm64: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release/10926/overview
Original change's description:
> [pku][wasm] Refactor PKU usage in Wasm
>
> RwxMemoryWriteScope becomes the bottleneck for both MAP_JIT and PKU
> machinery.
> Wasm and V8 code space will use the same memory protection key.
>
> This is a next step towards adding PKU support for V8 code space.
>
> Bug: v8:13023
> Change-Id: I647f8c09bc41e5ef8a1d74b58a48a43e08454e0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702213
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81947}
Bug: v8:13023
Change-Id: I11c52ac101804ab75b1bb1d4814f083cb1083d5b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780498
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#81949}
RwxMemoryWriteScope becomes the bottleneck for both MAP_JIT and PKU
machinery.
Wasm and V8 code space will use the same memory protection key.
This is a next step towards adding PKU support for V8 code space.
Bug: v8:13023
Change-Id: I647f8c09bc41e5ef8a1d74b58a48a43e08454e0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702213
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81947}
This reverts commit e895b7af73.
Reason for revert: TSAN failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/8468/overview
Original change's description:
> Background merging of deserialized scripts
>
> Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
> with which an embedder could request that V8 merge newly deserialized
> script data into an existing Script from the Isolate's compilation
> cache. This change implements those new functions. This functionality is
> still disabled by default due to the flag
> merge_background_deserialized_script_with_compilation_cache.
>
> The goal of this new functionality is to reduce memory usage when
> multiple frames load the same script with a long delay between (long
> enough for the script to have been evicted from Blink's in-memory cache
> and for the top-level SharedFunctionInfo to be flushed). In that case,
> there are two Script objects for the same script: one which was found in
> the Isolate compilation cache (the "old" script), and one which was
> recently deserialized (the "new" script). The new script's object graph
> is essentially standalone: it may point to internalized strings and
> readonly objects such as the empty feedback metadata, but otherwise
> it is unconnected to the rest of the heap. The merging logic takes any
> useful data from the new script's object graph and attaches it into the
> old script's object graph, so that the new Script object and any other
> duplicated objects can be discarded. More specifically:
>
> 1. If the new Script has a SharedFunctionInfo for a particular function
> literal, and the old Script does not, then the old Script is updated
> to refer to the new SharedFunctionInfo.
> 2. If the new Script has a compiled SharedFunctionInfo for a particular
> function literal, and the old Script has an uncompiled
> SharedFunctionInfo, then the old SharedFunctionInfo is updated to
> point to the function_data and feedback_metadata from the new
> SharedFunctionInfo.
> 3. If any used object from the new object graph points to a
> SharedFunctionInfo, where the old object graph contains a matching
> SharedFunctionInfo for the same function literal, then that pointer
> is updated to point to the old SharedFunctionInfo.
>
> The document at [0] includes diagrams showing an example merge on a very
> small script.
>
> Steps 1 and 2 above are pretty simple, but step 3 requires walking a
> possibly large set of objects, so this new API lets the embedder run
> step 3 from a background thread. Steps 1 and 2 are performed later, on
> the main thread.
>
> The next important question is: in what ways can the old script's object
> graph be modified during the background execution of step 3, or during
> the time after step 3 but before steps 1 and 2?
>
> A. SharedFunctionInfos can go from compiled to uncompiled due to
> flushing. This is okay; the worst outcome is that the function would
> need to be compiled again later. Such a risk is already present,
> since V8 doesn't keep IsCompiledScopes for every compiled function in
> a background-deserialized script.
> B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
> compilation. This is also okay; the merge completion logic on the
> main thread will just keep this lazily compiled data rather than
> inserting compiled data from the newly deserialized object graph.
> C. SharedFunctionInfos can be cleared from the Script's weak array if
> they are no longer referenced. This is mostly okay, because any
> SharedFunctionInfo that is needed by the background merge is strongly
> referenced and therefore can't be cleared. The only problem arises if
> the top-level SharedFunctionInfo gets cleared, so the merge task must
> deliberately keep a reference to that one.
> D. SharedFunctionInfos can be created if they are needed due to lazy
> compilation of a parent function. This change is somewhat troublesome
> because it invalidates the background thread's work and requires a
> re-traversal on the main thread to update any pointers that should
> point to this lazily compiled SharedFunctionInfo.
>
> At a high level, this change implements three previously unimplemented
> functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
>
> - BackgroundDeserializeTask::SourceTextAvailable, run on the main
> thread, checks whether there is a matching Script in the Isolate
> compilation cache which doesn't already have a top-level
> SharedFunctionInfo. If so, it saves that Script in a persistent
> handle.
> - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
> whether the persistent handle from the first step exists (a fast
> operation which can be called from any thread).
> - BackgroundDeserializeTask::MergeWithExistingScript, run on a
> background thread, performs step 3 of the merge described above and
> generates lists of persistent data describing how the main thread can
> complete the merge.
> - BackgroundDeserializeTask::Finish is updated to perform the merge
> steps 1 and 2 listed above, as well as a possible re-traversal of the
> graph if required due to newly created SharedFunctionInfos in the old
> Script.
>
> The merge logic has nothing to do with deserialization, and indeed I
> hope to reuse it for background compilation tasks as well, so it is all
> contained within a new class BackgroundMergeTask (in compiler.h,cc). It
> uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
> the object visitation that updates pointers to SharedFunctionInfos.
>
> [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
>
> Bug: v8:12808
> Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#81941}
Bug: v8:12808
Change-Id: I82a080e6287828445293cb6b4b94a5e8f15eb8f3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787213
Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#81943}
Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
with which an embedder could request that V8 merge newly deserialized
script data into an existing Script from the Isolate's compilation
cache. This change implements those new functions. This functionality is
still disabled by default due to the flag
merge_background_deserialized_script_with_compilation_cache.
The goal of this new functionality is to reduce memory usage when
multiple frames load the same script with a long delay between (long
enough for the script to have been evicted from Blink's in-memory cache
and for the top-level SharedFunctionInfo to be flushed). In that case,
there are two Script objects for the same script: one which was found in
the Isolate compilation cache (the "old" script), and one which was
recently deserialized (the "new" script). The new script's object graph
is essentially standalone: it may point to internalized strings and
readonly objects such as the empty feedback metadata, but otherwise
it is unconnected to the rest of the heap. The merging logic takes any
useful data from the new script's object graph and attaches it into the
old script's object graph, so that the new Script object and any other
duplicated objects can be discarded. More specifically:
1. If the new Script has a SharedFunctionInfo for a particular function
literal, and the old Script does not, then the old Script is updated
to refer to the new SharedFunctionInfo.
2. If the new Script has a compiled SharedFunctionInfo for a particular
function literal, and the old Script has an uncompiled
SharedFunctionInfo, then the old SharedFunctionInfo is updated to
point to the function_data and feedback_metadata from the new
SharedFunctionInfo.
3. If any used object from the new object graph points to a
SharedFunctionInfo, where the old object graph contains a matching
SharedFunctionInfo for the same function literal, then that pointer
is updated to point to the old SharedFunctionInfo.
The document at [0] includes diagrams showing an example merge on a very
small script.
Steps 1 and 2 above are pretty simple, but step 3 requires walking a
possibly large set of objects, so this new API lets the embedder run
step 3 from a background thread. Steps 1 and 2 are performed later, on
the main thread.
The next important question is: in what ways can the old script's object
graph be modified during the background execution of step 3, or during
the time after step 3 but before steps 1 and 2?
A. SharedFunctionInfos can go from compiled to uncompiled due to
flushing. This is okay; the worst outcome is that the function would
need to be compiled again later. Such a risk is already present,
since V8 doesn't keep IsCompiledScopes for every compiled function in
a background-deserialized script.
B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
compilation. This is also okay; the merge completion logic on the
main thread will just keep this lazily compiled data rather than
inserting compiled data from the newly deserialized object graph.
C. SharedFunctionInfos can be cleared from the Script's weak array if
they are no longer referenced. This is mostly okay, because any
SharedFunctionInfo that is needed by the background merge is strongly
referenced and therefore can't be cleared. The only problem arises if
the top-level SharedFunctionInfo gets cleared, so the merge task must
deliberately keep a reference to that one.
D. SharedFunctionInfos can be created if they are needed due to lazy
compilation of a parent function. This change is somewhat troublesome
because it invalidates the background thread's work and requires a
re-traversal on the main thread to update any pointers that should
point to this lazily compiled SharedFunctionInfo.
At a high level, this change implements three previously unimplemented
functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
- BackgroundDeserializeTask::SourceTextAvailable, run on the main
thread, checks whether there is a matching Script in the Isolate
compilation cache which doesn't already have a top-level
SharedFunctionInfo. If so, it saves that Script in a persistent
handle.
- BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
whether the persistent handle from the first step exists (a fast
operation which can be called from any thread).
- BackgroundDeserializeTask::MergeWithExistingScript, run on a
background thread, performs step 3 of the merge described above and
generates lists of persistent data describing how the main thread can
complete the merge.
- BackgroundDeserializeTask::Finish is updated to perform the merge
steps 1 and 2 listed above, as well as a possible re-traversal of the
graph if required due to newly created SharedFunctionInfos in the old
Script.
The merge logic has nothing to do with deserialization, and indeed I
hope to reuse it for background compilation tasks as well, so it is all
contained within a new class BackgroundMergeTask (in compiler.h,cc). It
uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
the object visitation that updates pointers to SharedFunctionInfos.
[0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
Bug: v8:12808
Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#81941}
The new method is not implemented in Chrome or Node, and the issue has
no activity since 2018, so let's rip out the incomplete new API.
Drive-by: Sprinke a few V8_LIKELY and V8_UNLIKELY.
R=mlippautz@chromium.org
Bug: chromium:634547
Change-Id: I0dabad520d459277d7196fa69c1bbceaf4d53596
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780528
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81923}
Sometimes the second Wasm instantiation fails because we run out of
memory. This raises a RangeError, which is not recognized by ClusterFuzz
as OOM.
Thus turn it into a proper OOM crash.
R=ahaas@chromium.org
Bug: chromium:1347024
Change-Id: I39f7789cc85a9ba9b4217764fbbcef15c6c6ed76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784602
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81920}
Whenever PagedNewSpace allocates a page, the page is added to the free
list. Preallocating pages on space initialization means the pages are
added to the free list before the map for free space is initialized.
Then, when allocating from the free list, a DCHECK fails
(free-list.cc:508).
This CL delays page preallocation until `EnsureCurrentCapacity` is
called. When using PagedNewSpace, we will call this method from
`Heap::CreateHeapObjects` after the maps are allocated and before any
allocations in new space are attempted.
Bug: v8:12612
Change-Id: I33f825ddd831640b12e4c0f7b849262a335df51e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780541
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81919}
All embedders override this method now, so it can be abstract.
R=mlippautz@chromium.org
Bug: v8:12425
Change-Id: I4db5d74341c9519222592a88d247bc2aa2be03a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780538
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81910}
This is a follow up to Iadf73c294904ec20cefe1053a2969aa1dbb91a39.
Bug: v8:7748
Change-Id: I59390b8c82c4ebed58f2d3130cd9b1578bffdd4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780535
Commit-Queue: Matthias Liedtke <mliedtke@google.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@google.com>
Cr-Commit-Position: refs/heads/main@{#81908}
Avoid most of the {is_inline()} checks by having a {data_begin_} pointer
which either points at the inline storage or at the zone-allocated
memory.
This replaces a dynamic branch by a memory indirection, which is
beneficial for big (non-inline) BitVectors. For small BitVectors we will
have to see what the bots say; the hypothesis is that a memory load is
still faster than a dynamic branch.
Apart from better performance, this change allows for simpler code in
many places, including the iterator implementation.
R=jkummerow@chromium.org
Bug: v8:13063
Change-Id: I1e28279d1a438598e0b8403a6a4078c2cd2a4c48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776685
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81902}
Drive-by fixes:
* categorize CodeDataContainer objects as kCode,
* when external code space is enabled report CodeDataContainers as
(%s builtin handle),
* replace a sequence of obj.IsXXX() with a respective sequence of
InstanceTypeChecker::IsXXX().
Bug: v8:11880
Change-Id: Ib50b168eb28af5f8388be7f9b9f4feba2ee784af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780534
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81898}
Make sure AddAllSequenceSlowCallback works on arrays where some
elements cannot be accessed.
Bug: chromium:1338877
Change-Id: Icdf61a305fb208a91832d03ebc47201d8941e41a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3778410
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81896}
Instead of creating the Suspender object in JS and passing it to the
stack-switching js-to-wasm wrapper, the wrapper now automatically
creates the Suspender object and forwards it as an extra parameter to
the wasm function. See:
https://github.com/WebAssembly/js-promise-integration/pull/1/filesR=ahaas@chromium.org
Bug: v8:12191
Change-Id: I2badee823f4223a293632f93e7e59f24c49d0820
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779688
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81890}
The DevTools frontend doesn't want the Wasm module's understanding of
function body offsets (i.e. including locals), but the ranges of
offsets where breakpoints can be set (i.e. only where instructions are).
This patch adjusts the reported offsets accordingly.
A consequence is that we have to report full (start,end) pairs for each
function, instead of being able to dedupe end1==start2 etc.
Bug: v8:12917
Change-Id: I0c7d2d96435cdac2c4553647b7bcc8783bc1798b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780526
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81887}
This CL adds Uint8Array as supported arguments for fast API calls.
It introduces a kUint8 variant to CTypeInfo for use with TypedArrays
only.
Bug: v8:13080
Change-Id: Ie65206078a18acabaafa9c95793f400b8e95373d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3767098
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81886}
This CL adds a new method to the `console` that is available
when DevTools is open. In TypeScript notation the API is:
```
namespace console {
// Creates a new `Task` and associates the current async
// stack trace with the created `Task`.
scheduleTask(name: string): Task;
}
interface Task {
// Executes an arbitrary payload and forwards the return value
// back to the caller. Any async stack trace captured during
// 'f' has the site of the corresponding `scheduleTask` as
// its parent.
run<T>(f: () => T): T;
}
```
The API is a saner user-facing API for our async stack trace
mechanism:
* scheduleAsyncTask corresponds to scheduleTask
* startAsyncTask/stopAsyncTask are called implicitly before `f`
is executed.
* cancelAsyncTask is called implicitly when `Task` is GC'ed
The API is behind the flag --experimental-async-stack-tagging-api
Bug: chromium:1334585
Change-Id: Ic6054279a108756caed6b4b5f2d1fe4a1bdbaf78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776678
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81881}
Add a second implementation of BalanceDuration which
the nanoseconds could be very large and beyong the precision
could be handled by double and passed in by BigInt, and values
of other time fields are 0.
Bug: v8:11544
Change-Id: Ib794c6c78b81b8338434314fa5033cf1e991d32b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3781117
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81876}
Add a test where the GC gets called during parameter conversion, and fix
two related issues:
- Reorder spilled references so that they are at the top of the stack
before the builtin call
- Add the missing frame marker on the new stack
R=ahaas@chromium.org
Bug: v8:12191
Change-Id: I3f68c675123c726543df6942d110fe06bc6c0efb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780530
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81873}
Some tests and testing infrastructure had to be changed because it
relied on nominal types.
Drive-by: Support function supertypes in wasm-module-builder.js.
Bug: v8:7748
Change-Id: Ife92431d1842ff9de91e296a50421aa48f02c0de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776197
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81862}
In order to make the shared code write barrier thread-safe, we simply
lock the page mutex when appending to the typed_slot_set. We can later
improve this when performance isn't good enough.
Bug: v8:13018
Change-Id: I5e12f83f459f8976c22ec488cfa9b6f16d4a8a8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763867
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81855}
Instead of one big test which tests multiple functions, split the unit
test into multiple smaller tests.
Also, use TestWithZone instead of TestWithIsolate, because the isolate
is never used.
R=jkummerow@chromium.org
Bug: v8:12425
Change-Id: I32148e40b5ed2b006cc647d42bdfe564ccc6d0ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776676
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81852}
This way we make tests more flexible wrt. future changes, especially
when it comes to module offsets.
Bug: v8:12868
Change-Id: Ie99806603603e5c731c61267469b14f81c88ffac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776195
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81846}
This CL hardens a test to avoid static_cast-ing doubles that don't fit
into the 32-bit integer range.
Bug: chromium:1344965
Change-Id: I1f3a05800158cda9dc582bfa4427516932db9679
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776337
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81843}
We will provide a replacement for raw pointers in future which should
only be used by backing stores. Any other callsite must go through
Trace(BasicMember<>).
Bug: v8:13089
Change-Id: Ibdae439b44ad94bd7af2532855be941c5334db99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3772328
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81833}
The suspender is only needed by the wrapper, do not forward it to the JS
import.
R=ahaas@chromium.org
Bug: v8:12191
Change-Id: Id8e9a820491588b40fffb5dfd8706e85a16b8b23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3768410
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81818}
Thread through compressed pointer into write barrier to allow to delay
compression after checking whether a write barrier is actually needed.
Change-Id: If7e6cbb69a57cc9aeeb551c11f685bace4e56c4c
Bug: chromium:1325007
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769826
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81816}
... when external code space is enabled.
Currently this mode is guarded by V8_REMOVE_BUILTINS_CODE_OBJECTS flag
which is set to false until Code-less builtins are supported.
Drive-by:
* remove unnecessary methods from AbstractCode,
* avoid CodeDataContainer <-> Code roundtrips when accessing writable
state of Code objects via CodeT.
Bug: v8:11880
Change-Id: Iae3ff3b2feae68d875cbe9f82a6bb076460dd2f8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769832
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81814}
This includes several changes:
- avoid a very-unlikely-but-theoretically-possible OOB write
- avoid a somewhat-likely memory leak
- grow the buffer less aggressively for medium-length strings
Change-Id: I877f43d7e2e7cd4778ba8c7c7525ba988301f750
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3771900
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81808}
This CL fixes a bug in the units of the reported metrics for
V8.GC.Cycle.MainThread.Full.Incremental.Mark (ms instead of us).
It also reports incremental marking/sweeping metrics (both for the
unified heap and the C++ managed heap) only when incremental
marking/sweeping were used; otherwise, no zero values are reported.
Bug: chromium:1154636
Bug: chromium:1343507
Change-Id: Ibc0103ea62fa0eeb5f7184280c8514e99a5c21a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3768502
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81803}
This adds a bunch of tracing hooks to the module decoder and uses
them to support "annotated hexdump" output for full modules in wami:
$ out/x64.release/wami my_module.wasm --full-hexdump
Change-Id: I5821d940b5ec236df9708eecd0124172d8893ffd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3754741
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81791}
... in order to avoid expensive computation of cage_base for Code
objects and in order to avoid issues with wrong cage base values
computed from Code objects in external code space.
Drive-by: cage-bas'ify some accessors in JSFunction and Code.
This is a step towards Code-less embedded builtins.
Bug: v8:11880
Change-Id: I95dd8bcd4680e09c7463e1bc7d72dcbf9f2e5c1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769831
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81788}
- Removed duplication and unnecessary indirection from all suites testcfgs.
- Introduced a more comprehensive context to cover both command context and other platform specific concerns.
- Propagated above context to TestLoader to allow for test counting command execution on all platforms.
- Wrapped original pool with another class to give it a new interface and allow injecting different implementations in the future.
- Consolidated progress indicators under a single processor in the pipeline.
- Consolidated result retention requirements calculation outside of pipeline chain.
- Refactored LoaderProc and got it under tests.
- Added some more tests for the standard runner.
- Extracted BuildConfig class.
Bug: v8:12785
Change-Id: I87be040e91f792a983662bb5a10d55b36a14ea7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3701595
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81770}
- Avoid adding an Invalid type that can never be reached during
traversal;
- Expose class names as object names;
Bug: chromium:1321620
Change-Id: Ie3d9f78d97703535ecf67d56235d564ab6a9a7e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763866
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81758}
Currently the same reduction is used for both TypedArray's and
DataView's byte{Length,Offset} accessors. But their behavior differ on
detached buffers: TypedArray returns 0 while DataView throw.
Do not do the optimization for DataViews if we can't depend on the
detach protector.
Bug: chromium:1344549
Change-Id: I38b533a62f756869380cb5c19fe254e03979e81a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763785
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81754}
By about 10x-20x depending on platform and configuration.
Shorter test strings make the set of all possible substrings
considerably smaller.
Fixed: v8:13074
Bug: v8:12868
Change-Id: I46ae94fbcba43080d06b1b825feae6b2acf819d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763861
Reviewed-by: Andy Wingo <wingo@igalia.com>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81753}
This CL refactors the implementation of inner pointer resolution, based
on the marking bitmap. MarkCompactCollector::FindBasePtrForMarking has
most of its code that processes the marking bitmap moved to a utility
function FindPreviousObjectForConservativeMarking, which iterates
backwards to find the closest previous object on the page that has been
marked.
Bug: v8:12851
Change-Id: I980ac5712d8b1df792196d77edb9526ca2e13e2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3758227
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81750}
As sandboxed pointers are now default-enabled when the sandbox is
enabled, it is no longer possible to deactivate the sandbox at runtime.
This CL therefore removes all the logic that was required to support a
sandbox that could be disabled at runtime, moves the initialization of
the sandbox into V8::Initialize, and deprecates V8::InitializeSandbox.
This change also makes the sandbox initialization deterministic if
FLAG_random_seed is supplied.
Bug: v8:10391
Change-Id: Ibd49f7c251b7c58c642f18a551ecc2c391740970
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/+/3762583
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81746}
Raw data access is already possible via GetBackingStore()->GetData().
This API exposes a more efficient way for accessing
JSArrayBuffer::backing_store (which, despite the confusing name, is no
the BackingStore but its raw data pointer).
Bug: v8:10343
Change-Id: I695cea91e2c3de75ce6c86bac6e413ce6617958b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3764341
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81745}
It's flaky in that config, and the failures are not considered actionable.
Bug: v8:12267
Change-Id: Ibc020cd7d28ddda431ec5f79f3c1952a14ffbfa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763582
Auto-Submit: Adam Klein <adamk@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@{#81728}
Test was already skipped for quite some time.
Bug: v8:8169
Change-Id: I1cb4f024e43a42c48b425ad0c713fb85bbfb2354
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762580
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81727}
As sandboxed pointers assume a constant sandbox size (they are
essentially n-bit offsets), it is no longer useful to be able to create
smaller sandboxes. This CL simplifies the sandbox initialization logic
accordingly and adds CHECKS to ensure a fixed-size sandbox is created.
Bug: v8:10391
Change-Id: I6541ab769001e60c0256d3a719f926128a0a20b0
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/+/3647684
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81720}
Errors in the callback were not correctly unlocking the mutex, oops.
Bug: v8:12547
Change-Id: If44ebc023b8192605c9f29bfd4099a197110f5c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3760986
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81708}
To prevent timeouts on arm64-sim debug and gc-stress builder. Also
skip a very slow test on the arm64-sim gc-stress builder.
No-Try: true
Change-Id: I7d275aa893dbe4942b4d41c6e83d9b9e6f861a33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3760455
Reviewed-by: Adam Klein <adamk@chromium.org>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81704}
The operator with raw pointer allows us to avoid Member decompression,
which is more expensive than compression. It's also quite frequently
called (e.g. in HeapHashSet::find()).
The existing operator
template <...>
bool operator==(const Member<T1>&, const Member<T2>&);
was not called for
GCed* raw = ...;
member == raw;
because the compiler wouldn't deduce `T2` in `const Member<T2>` as
`GCed` when the initializer expression `raw` is of different type
(`GCed*`).
Bug: chromium:1325007
Change-Id: Ie1ee12bad28081c66f4e08a146467fd7c040bb70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3757344
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81702}
Bug: chromium:1344014
Change-Id: I5009af963d95d96f70785593664a1145ad20c97d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3760975
Reviewed-by: Adam Klein <adamk@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81701}
When the control-flow aware type of a Node doesn't actually change,
then we shouldn't claim that it did (which causes later re-visiting
of the node).
Fixed: v8:13061
Change-Id: I064cedf3721a79844bfc36ad3142428bdfbaf891
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3760675
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81700}
TSAN may cause the sandbox to fail to obtain enough virtual address
space during initialization, thereby causing it to fall back to a
smaller backing reservation. This may then in turn cause future
WebAssembly.Memory allocations to fail.
Bug: v8:12980
Change-Id: I812ee02c5421153f1ea3b6bc371c72bc1da406a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3757897
Commit-Queue: Samuel Groß <saelo@chromium.org>
Auto-Submit: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81686}
This adds a new type 'none' as part of the WASM GC MVP.
The type can only be used in combination with a nullable reference, e.g.
'ref.null none'.
A 'nullref' is implicitly convertible to any nullable reference type.
Bug: v8:7748
Change-Id: Ic5ab6cc27094b3c9103ce3584452daa34633612f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3755136
Auto-Submit: Matthias Liedtke <mliedtke@google.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81670}
If we detect out-of-order sections, we should not enter the individual
decoding functions, because they might make assumptions that are not
true in the error case.
In this case, a DCHECK was firing if we call {DecodeFunctionSection}
twice.
R=ahaas@chromium.org
Bug: chromium:1342274
Change-Id: I3d9d8c8c604aeeb92b9766f07d4b5464f4c8d72c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3755112
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81662}
With the flag --always-use-forwarding-table we could end up turning a
String into a ThinString that had a forwarding index set.
This could happen when a String with a forwarding index is externalized.
Bug: chromium:1337469
Change-Id: Iea05586f61e2b78d83d04d5d2e94c4dca2892c1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3735164
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81660}
