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}
Duplicate the logic of trying to build Int32 comparisons to also try to
build Float64 comparisons if preceeding a branch. Also, make sure to do
the opposite (emit a tagged value) for the internalized string compare
case.
Bug: v8:7700
Change-Id: Ib34761fa0fdc26d4ad9b6adb960b0b17ec8e1f21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762582
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81742}
After last refactoring of ETW generation, I introduced a regression
in the method that checks when SourceLoad should happen, and
reverted the condition used to know if a new SourceLoad should
happen.
Bug: v8:12932
Change-Id: I69f5d0700f6af9b124bb0f55750c8d91e56e9e0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762585
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: José Dapena Paz <jdapena@igalia.com>
Cr-Commit-Position: refs/heads/main@{#81741}
This CL adds a new vector scratch reg to PPC (v15)
and uses it during Simd swap operations.
Functions are also changed to accept scratch registers
as input.
Change-Id: I0220504ddf154148d2b83207b42ab2b7a794698c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763863
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#81733}
The header is only slightly refactored:
* function names are slightly shortened,
* global functions and enums are converted to static methods and enums
of a MemoryProtectionKey class.
This is a first step towards adding PKU support for V8 code space.
Bug: v8:13023
Change-Id: Iebcb075b07286d18d6834fbcf6697327f08c9f50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762584
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81732}
This reverts commit 8218c06158.
Reason for revert: compile failures, e.g.:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release%20builder/11040/overview
Original change's description:
> [wasm] Reset PKRU before spawning new threads
>
> We sometimes hit the DCHECK in the wasm code manager:
> DCHECK_IMPLIES(writable, !MemoryProtectionKeyWritable());
>
> This is because we spawn new threads while having a
> {CodeSpaceWriteScope} open. In the case of PKU, this changes the PKRU
> register to allow writes to the code space, and the value of that
> register is inherited by any new thread. If this thread then tries to
> switch to writable code spaces, it hits the DCHECK. It would hit a
> similar DCHECK when trying to execute code.
>
> We fix this issue by temporarily resetting the PKRU register to
> non-writable while we call the {NotifyConcurrencyIncrease} method. This
> is not a very robust solution, as any new call that potentially happens
> inside a {CodeSpaceWriteScope} needs to do the same, but refactoring the
> code to avoid spawning new threads while being in writable state would
> be a lot of work with other downsides.
>
> R=jkummerow@chromium.org
>
> Bug: v8:13075
> Change-Id: Ibc7270aa597902dc6d9649cb6bcdfce8b1a9bafc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762579
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81729}
Bug: v8:13075
Change-Id: I235e7263856a37cf0f4aa1c27493aac8e6db7910
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763587
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81730}
We sometimes hit the DCHECK in the wasm code manager:
DCHECK_IMPLIES(writable, !MemoryProtectionKeyWritable());
This is because we spawn new threads while having a
{CodeSpaceWriteScope} open. In the case of PKU, this changes the PKRU
register to allow writes to the code space, and the value of that
register is inherited by any new thread. If this thread then tries to
switch to writable code spaces, it hits the DCHECK. It would hit a
similar DCHECK when trying to execute code.
We fix this issue by temporarily resetting the PKRU register to
non-writable while we call the {NotifyConcurrencyIncrease} method. This
is not a very robust solution, as any new call that potentially happens
inside a {CodeSpaceWriteScope} needs to do the same, but refactoring the
code to avoid spawning new threads while being in writable state would
be a lot of work with other downsides.
R=jkummerow@chromium.org
Bug: v8:13075
Change-Id: Ibc7270aa597902dc6d9649cb6bcdfce8b1a9bafc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762579
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81729}
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}
The {std::min} followed by a loop does ensure that the new length is
bigger than {needed_value}, but does not ensure that we always allocate
at least {kInitialLength}. Maybe this was intended to be {std::max}?
Anyway, this CL replaces the loop by a computation which ensures that we
allocate a power of two that is greater than {needed_value} and at least
{kInitialLength}.
It also adds a CHECK to guard against integer overflows.
R=jkummerow@chromium.org
Bug: v8:13063
Change-Id: I374d304204a499536643a6c5df7111231d41d4bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3760674
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81724}
When testing the serializer (e.g. via --stress-snapshot), raw external
references (i.e. just raw pointers) can be embedded inside the snapshot.
When those pointers are sandboxed, the corresponding external pointer
tag also needs to be encoded in the snapshot. This CL adds the necessary
logic to support this by introducing new serializer Bytecodes for raw
external references and encoding the raw pointers together with the tag.
Bug: v8:10391
Change-Id: I7b3710c2144e19f7507e3f6db537d250d102ee28
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/+/3762575
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81723}
This extends the idea already used by "MaterializeMergedConstants":
certain values have to be processed by every br*, so to protect against
cascades of conditional jumps causing lots of repeated work, it makes
sense to do such processing just once.
For the module in the linked bug, this reduces Liftoff generated code
size from 69MB to 181KB.
Fixed: v8:13072
Change-Id: Ie9f98240e93751988067d4774d4a09b2b39bdad6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3760444
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81722}
Avoid materializing a compressed value into a register if that value is
only used for a compare afterward. Instead, emit it directly as an
immediate on the cml. We can only do this for the Cmp(Register,...)
overload, not Cmp(Operand,...), since the latter already has the lhs as
a complex operand.
Change-Id: I99f192c9919e401164d31d2e2e1c3a0c21a6aaf0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762577
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81721}
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}
Use the Operand overload of Cmp to avoid loading the object map into a
temporary in CheckMaps; this also avoids uncompressing the map pointer
when loading it.
It does mean that the migration path of CheckMapsWithMigration has to
re-load the map, and heavier use of the scratch register in that
implementation, but it's a deferred path so that should be ok.
Bug: v8:7700
Change-Id: I6741d5b5a8ad402bdef9025c43a86aca21db050e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762574
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81719}
This change alone reduces the overall compile time of the reproducer
from the linked issue by >30%.
R=jkummerow@chromium.org
Bug: v8:13063
Change-Id: I5ac69ab6ec2f1427b1511181664d34f4b1d26f93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3760451
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81714}
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}
PPC Simd regs are already using separate set of register banks
on ppc, more details can be found here:
https://crrev.com/c/2718472
Here we are making use of this CL https://crrev.com/c/3005768
(fcd3ef4) and fully separating Simd regs during register allocation.
Member function `toSimd()` is also introduced which will be used
to cast FP regs to Simd regs in liftoff.
Change-Id: Ic5551fb04f37de7fc9501a2f1aba8fb44f622d95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3755213
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81707}
The current compression scheme defines isomorphism with respect to
relational operations (i.e. the relational operators preserve their
results on the set of compressed pointers).
In addition, provide overloads for nullptr/sentinel.
Bug: chromium:1325007
Change-Id: I476a1c59e92f5210e26142320eb03802bd11ea51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3758143
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81706}
The increase caused a significant PMF regression on Windows. Apparently,
leaving the table in reserved state didn't eliminate the regression. The
CL returns the age size back to 1MB. The followup is to investiage and
fix the regression.
Bug: chromium:1336420
Change-Id: I56542ba4efe0fc8d08d8c5febf758384559a8860
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3758146
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81705}
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}
Implements an initial prototype of the Wasm Trace proposal. A custom
section containing offsets to functions is decoded into trace
instructions that are inserted into the function. In Liftoff, these
are directly inserted. In TurboFan, these are added as StackEffect's,
this is a work in progress.
Traces will only be decoded and added when a flag is given to V8,
currently "--experimental-wasm-instruction-tracing". If a trace is ever
not valid or an error occurs, it is safe to just throw them away.
Code Metadata Tool Convention:
https://github.com/WebAssembly/tool-conventions/blob/main/CodeMetadata.md
Design Doc:
https://docs.google.com/document/d/1739a_LXbavBnek7pa0uqhHOCz8IJ56mn2C2Yvbssvkg/edit?usp=sharing
Wasm Trace Proposal:
https://github.com/WebAssembly/instrument-tracing
Bug: chromium:1090122, chromium:1252113
Change-Id: Id4690d8deca482ff0e863761668ffabca159bd29
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386604
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81699}
V8 was compiled for Fuchsia with optimize_speed instead of optimize_max
used on most other platfroms. There is no reason Fuchsia needs to be
different, so it's better to use optimize_max. It also allows to save
about 1MB on the binary size.
Bug: chromium:1343990
Change-Id: Ie4a07fbbfd8100def61bf7709d2c4e6cb74209f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3759647
Commit-Queue: Sergey Ulanov <sergeyu@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Sergey Ulanov <sergeyu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81698}
