This adds `extern.internalize(ref null extern): ref null any` to wasm
which unpacks the wrapped wasm object if the js-interop flag is not set.
I31 values are still wrapped in object wrappers and don't use SMIs.
Bug: v8:7748
Change-Id: Ie4a4507961d0ad41caf430054a3d341f474b8e66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819645
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82426}
This has been broken even prior to the any <-> extern split.
The code decided to use the generic wrapper for type any even though
the generic wrapper doesn't support wrapping the return value of functions
and unwrapping arguments passed to it.
Bug: v8:7748
Change-Id: I9dbb893cc4bc4f2bb789b3b3a9addd0208d526ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3826056
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82424}
Bug: v8:13181
Change-Id: I8eaa84ffc408225ee28dca17607b940fd3f34977
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3826068
Commit-Queue: Adam Klein <adamk@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82414}
This reverts commit cf765fc348.
Reason for revert: fixes more tests than expected in test262:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20shared/49412/overview
Original change's description:
> [Temporal] Use double instead of int32_t for input of BalanceTime
>
> To avoid overflow int32_t in the math of balancing time.
>
> Bug: v8:13182, v8:11544
> Change-Id: Ib76cf95bbd4f9b47efd6921a67b09d3024e72b13
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827310
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82409}
Bug: v8:13182, v8:11544
Change-Id: Id7dd491b4485d13b0e2cc6aae8603479c7949ce8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827670
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@{#82413}
To avoid overflow int32_t in the math of balancing time.
Bug: v8:13182, v8:11544
Change-Id: Ib76cf95bbd4f9b47efd6921a67b09d3024e72b13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827310
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82409}
Remove the unnecessary int64_t version of RoundNumberToIncrement
and remove the unneeded RoundHalfAwayFromZero. Change the type of the
increment to double from int64_t.
split from cl/3750098
Bug: v8:11544
Change-Id: I591486c472e9c1343306ff9a1d0384d06fe01835
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3824194
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82403}
So far, we decoded instructions with the 0xFB prefix as two-byte, i.e.
a single "u8" byte following the prefix.
This patch changes that to 0xFB + LEB, which is how all prefixed
instructions are supposed to do it. Currently this makes a difference
only for the stringref proposal (instructions 0x80 through 0xb3).
It has the unfortunate consequence that all stringref instructions need
three bytes for now. We expect them to go back to a two-byte encoding
scheme (while remaining LEB compliant) when their final encoding is
decided.
Bug: v8:12868
Change-Id: I603f60adae88e9b985cb65288d9eeb7f98da8138
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3825887
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82400}
This is a reland of commit 9d36b2dd0d.
The test case is fixed to actually protect a part of the data section
instead of the stack (which was unintended and could lead to segfaults).
Original change's description:
> [base] Add new API to protect data memory
>
> This adds a new {base::OS::SetDataReadOnly} method, which is similar to
> {SetPermissions(kRead)}, but using another system call on Windows such
> that it works on pages in the data segment.
> {VirtualAlloc} will fail if called on a page of the data section,
> whereas {VirtualProtect} succeeds. For the general {SetPermissions}
> API we still want to use {VirtualAlloc} though, as it also changes the "committed" state of the pages.
>
> Note that we do not add a platform API for this, as the memory was
> never allocated through the platform. We just directly protect it in
> V8.
>
> R=mlippautz@chromium.org
>
> Bug: v8:12887
> Change-Id: If83bf6e5c500cc5cf08c76d04dfac5e2b4d35a2d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820482
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82349}
Bug: v8:12887
Change-Id: Ib7c24b43b53d568dafb4a56cf8db7479c784e8d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3825889
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82398}
... in compiler and other components.
Bug: v8:11880
Change-Id: I3a51c33499e7c7169f171c4be0600d7822dafc27
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3825883
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82391}
This CL removes the bailout when trying to collect the scope info
for the class member initializer function. While this might not have
worked previously, now we only need to tweak the scope search
slightly to fix this. Class member initializer functions never
have their own context but instead us the class context. That means
that most of the logic in debug-scopes.cc doesn't really matter and we
only need to initialize the ScopeIterator properly with the class
context and the member initializer JSFunction.
Note that this still does not fully fix bug 1350842. That is because
we still run into a DCHECk when paused at a `new class { ... }`
statement. We'll fix that in a separate CL.
R=bmeurer@chromium.org
Bug: chromium:1350842
Change-Id: Id128b10676a5aa8a77309735e755e485f2c14446
Fixed: chromium:1246889
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3825881
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82387}
This function should properly forward any exceptions it encounters,
instead of silently swallowing them. Being an API function, that
means moving them from "pending" to "scheduled" state.
Fixed: v8:13123
Change-Id: I20b0782fd806e456f14dda84100000c857481d09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3825880
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82386}
This is a reland of commit 532ca59910
Fix interger overflow when result_location is invalid in
MaglevCompiler::InReturnValues.
Original change's description:
> [maglev] Support LdaModuleVariable and StaModuleVariable
>
> Bug: v8:7700
> Change-Id: I036ac71324e0c1c96a4da4aacdb5a6718726db31
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3821203
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: 王澳 <wangao.james@bytedance.com>
> Cr-Commit-Position: refs/heads/main@{#82347}
Bug: v8:7700
Change-Id: I24f56691eefd1c6cb695fedd3b5c14264bb17943
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3824942
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82379}
We have a bug report from 2018 that no longer reproduces on ToT.
This CL adds a regression bug regardless to make sure we don't
re-introduce the bug that got fixed as a side-effect.
R=kimanh@chromium.org
Fixed: chromium:1246896
Change-Id: I8f9fdcbf7051b23e03cbbfc572771a410f70ad37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3822668
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82372}
This is a reland of commit b1020a4345
Changes since revert:
- Fixed global safepoint interrupts in
https://chromium-review.googlesource.com/c/v8/v8/+/3820913
Original change's description:
> Reland "[shared-struct] Add Atomics.Condition"
>
> This is a reland of commit e2066ff6bf
>
> Changes since revert:
> - Rebased against c991852491, which
> uses the external pointer table for the WaiterQueueNode stored
> in the state field when compressing pointers. This relaxes
> the alignment requirement of the state field to be 4-bytes when
> compressing pointers.
> - Moved the state field into the JSSynchronizationPrimitive base
> class, since alignment and padding can now be made simpler.
>
> Original change's description:
> > [shared-struct] Add Atomics.Condition
> >
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630350
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Reviewed-by: Adam Klein <adamk@chromium.org>
>
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763787
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Bug: v8:12547
Change-Id: Ibc6de74c7853e4ea766ff2c70f92339ba69f2675
Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820901
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82368}
This reverts commit 9d36b2dd0d.
Reason for revert: Win64 crashes
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20debug/43496/overview
Original change's description:
> [base] Add new API to protect data memory
>
> This adds a new {base::OS::SetDataReadOnly} method, which is similar to
> {SetPermissions(kRead)}, but using another system call on Windows such
> that it works on pages in the data segment.
> {VirtualAlloc} will fail if called on a page of the data section,
> whereas {VirtualProtect} succeeds. For the general {SetPermissions}
> API we still want to use {VirtualAlloc} though, as it also changes the "committed" state of the pages.
>
> Note that we do not add a platform API for this, as the memory was
> never allocated through the platform. We just directly protect it in
> V8.
>
> R=mlippautz@chromium.org
>
> Bug: v8:12887
> Change-Id: If83bf6e5c500cc5cf08c76d04dfac5e2b4d35a2d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820482
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82349}
Bug: v8:12887
Change-Id: I86fffa60d6766dcdaf44f57f18266fec22eb9016
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3824409
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82360}
The zone-allocated objects, the destructor is never called. Such
objects must therefore never contain members that themselves have
non-trivial destructors, e.g. std containers.
Fix occurrences of this antipattern in Maglev.
Bug: v8:7700
Change-Id: I6892cf5203bb6e842397fd4292918b18134f97cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3822672
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82358}
ML-TF tiering remains very similar to Ignition-TF tiering:
- When the interrupt budget is exhausted, enter the TieringManager
which potentially decides to tier up and sets the appropriate
TieringState on the FeedbackVector.
- The prologue on ML function entry recognizes the TieringState (and
also available cached TF code) and starts compilation and/or jumps
into optimized code.
TODOs:
- ML-to-TF OSR is not yet supported.
- ML code is no longer cached on the FeedbackVector.
- Tracing is rudimentary.
- The generated function-entry prologue is fairly large and must be
either minimized or extracted into a builtin.
- Tiering involving Sparkplug is not entirely robust yet (Sparkplug
code may be installed with unexpected timing).
Bug: v8:7700
Change-Id: I86b0692477f51b9967f318a4093bc874344120b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629149
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82351}
This adds a new {base::OS::SetDataReadOnly} method, which is similar to
{SetPermissions(kRead)}, but using another system call on Windows such
that it works on pages in the data segment.
{VirtualAlloc} will fail if called on a page of the data section,
whereas {VirtualProtect} succeeds. For the general {SetPermissions}
API we still want to use {VirtualAlloc} though, as it also changes the "committed" state of the pages.
Note that we do not add a platform API for this, as the memory was
never allocated through the platform. We just directly protect it in
V8.
R=mlippautz@chromium.org
Bug: v8:12887
Change-Id: If83bf6e5c500cc5cf08c76d04dfac5e2b4d35a2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820482
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82349}
This is a reland of commit 6953b5550e
The reland fixes tests that retrieved the stack start from a
non-inlined frame's fp. This does not work in certain configurations
as the resulting marker is too low to consider the first local
variables in subsequent calls.
The fix uses an inline frame address for the tests to get an upper
bound of stack addresses to consider.
Original change's description:
> [handles] Remove precise on-stack representation of global handles
>
> Since https://crrev.com/c/3806439 on-stack traced handles are marked
> conservatively when being used in combination with CppHeap.
>
> This change removes the precise on-stack representation of the
> internal traced nodes as they nodes would anyways be marked
> conservatively. The effects are:
> - cheaper representation (just a single node space);
> - uniform handling: no checks to distinguish on-stack vs on-heap;
> - no brittleness around cleaning on-stack handles when the event loop
> is empty;
>
> Change-Id: Id859623bfed77a66bdd064ea8065536264515eae
> Bug: v8:13141
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3812039
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82306}
Bug: v8:13141
Change-Id: I53ece36220e99d02be6df18f83c18450e5d5037b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820585
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82342}
Growing Wasm memory is allowed to fail nondeterministically.
I checked locally that this is indeed what is making this test fail in
--verify-predictable mode.
R=jkummerow@chromium.org
Bug: v8:13167
Change-Id: I91d21c91481ac692a9f6000be45d43d517e76cd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3822684
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82341}
This CL adds a small inspector test to verify that Runtime.evaluate
with silent on/off can be interleaved while replMode is true for all
evaluations.
This is to check that the interaction between console and live
expressions works as expected when the user enables
"Pause on exceptions".
R=bmeurer@chromium.org
Bug: chromium:1335439
Change-Id: Iebd3f9f207312dc6dcd3d0b9a8483ef09608528f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3822685
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82337}
... which affect how builtin calls are generated.
This CL replaces the following boolean options
- builtin_calls_as_table_load,
- inline_offheap_trampolines,
- short_builtin_calls,
- use_pc_relative_calls_and_jumps,
with an enum BuiltinCallJumpMode and a boolean option
use_pc_relative_calls_and_jumps_for_mksnapshot.
Bug: v8:11880, v8:11527
Change-Id: Ia842b1d126c99dbe83e5b4f6118dcd44082ed168
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820063
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82330}
This CL includes:
1) Using 1 full GC instead of 2 young GCs to force object promotion.
2) A couple of needed bailouts.
3) Using manual evacuation candidates in old space to ensure an object
is evacuted (moved to a different address) instead of relying on
Scavenger.
And some other minor tweaks
Bug: v8:12612
Change-Id: Idfd925ccdf30215998ab6e7cc632ce750fa2077a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3816661
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82327}
{memory-protection-unittest} assumes that code objects exist after
compilation. This is not true with lazy compilation. Therefore this
CL disables lazy compilation in the test.
R=clemensb@chromium.org
Bug: v8:12852
Change-Id: I66039319fdfe4354afb32064e3e9105d334f5b07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819643
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82325}
This CL tries to improve readability of TryMarkingComplete() by
splitting it up into multiple smaller methods.
It also removes StepResult::kWaitingForFinalization since this was
only used in one test which could easily be rewritten to not need this
value. This makes CombineStepResult() and Step()s return value simpler
to understand.
Bug: v8:12775
Change-Id: I981bc7b736246ab53058d1e61e3c67db0d1130b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3816668
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82319}
This pr refactor all usage of v8_str in unittests/ into NewString
method in test-utils.h
Change-Id: I8ffc456851488e8c050d7a38f5459aebfa3f314f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3813064
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#82314}
This reverts commit 6953b5550e.
Reason for revert: Failing on CI: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20full%20debug/22876/overview
Original change's description:
> [handles] Remove precise on-stack representation of global handles
>
> Since https://crrev.com/c/3806439 on-stack traced handles are marked
> conservatively when being used in combination with CppHeap.
>
> This change removes the precise on-stack representation of the
> internal traced nodes as they nodes would anyways be marked
> conservatively. The effects are:
> - cheaper representation (just a single node space);
> - uniform handling: no checks to distinguish on-stack vs on-heap;
> - no brittleness around cleaning on-stack handles when the event loop
> is empty;
>
> Change-Id: Id859623bfed77a66bdd064ea8065536264515eae
> Bug: v8:13141
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3812039
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82306}
Bug: v8:13141
Change-Id: I5ebb2ed9eeec1394c2dd48504e91f6ff789b0711
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820584
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82313}
Since https://crrev.com/c/3806439 on-stack traced handles are marked
conservatively when being used in combination with CppHeap.
This change removes the precise on-stack representation of the
internal traced nodes as they nodes would anyways be marked
conservatively. The effects are:
- cheaper representation (just a single node space);
- uniform handling: no checks to distinguish on-stack vs on-heap;
- no brittleness around cleaning on-stack handles when the event loop
is empty;
Change-Id: Id859623bfed77a66bdd064ea8065536264515eae
Bug: v8:13141
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3812039
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82306}
This is a reland of commit 30ee069059
Avoid terminating from another thread in unit tests to make the termination of optimized bigint multiplication deterministic on windows
Original change's description:
> Reland "[TurboFan] Support BigIntMultiply"
>
> 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}
Bug: v8:9407
Change-Id: I7d04897f4e8f260aba31dbad55ce1263406473d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819621
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82304}
This reverts commit 9cca4e60f1.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20debug%20-%20single%20generation/6185/overview
Original change's description:
> [heap] Handle old-to-new slot promotion to shared heap
>
> The GC might promote an in-place internalizable string from new space
> directly into the shared heap. This means that the GC might need to
> create OLD_TO_SHARED slots when updating OLD_TO_NEW slots.
>
> This CL implements this both for minor and full GCs.
>
> Bug: v8:11708
> Change-Id: I6102b9024d1dd5dd602d654b006ea5897ab5baa6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804604
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82298}
Bug: v8:11708
Change-Id: I4cfdcff22552ff92ec85497d58021e83a6e038b0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819647
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Owners-Override: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82303}
The GC might promote an in-place internalizable string from new space
directly into the shared heap. This means that the GC might need to
create OLD_TO_SHARED slots when updating OLD_TO_NEW slots.
This CL implements this both for minor and full GCs.
Bug: v8:11708
Change-Id: I6102b9024d1dd5dd602d654b006ea5897ab5baa6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804604
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82298}
Splitting off cosmetics and unrelated test refactorings from a larger
CL reworking traced global handles.
Bug: v8:13141
Change-Id: I675cdbd4898346ab55b0db65d53e992f2eb95744
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3816671
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82295}
StepOrigin is enough to infer the right completion action: Either
finalization by task (for StepOrigin::kTask) or stack guard
(for StepOrigin::kV8).
Only tests with StepOrigin::kV8 were violating this but they also just
pass when enabling the stack guard.
Bug: v8:12775
Change-Id: I5df50198d8e3612ee97142f84bd497820a5cec78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3816664
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82294}
This reverts commit b1020a4345.
Reason for revert: Causes timeout for `condition-workers`: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/40516/overview
Original change's description:
> Reland "[shared-struct] Add Atomics.Condition"
>
> This is a reland of commit e2066ff6bf
>
> Changes since revert:
> - Rebased against c991852491, which
> uses the external pointer table for the WaiterQueueNode stored
> in the state field when compressing pointers. This relaxes
> the alignment requirement of the state field to be 4-bytes when
> compressing pointers.
> - Moved the state field into the JSSynchronizationPrimitive base
> class, since alignment and padding can now be made simpler.
>
> Original change's description:
> > [shared-struct] Add Atomics.Condition
> >
> > Bug: v8:12547
> > Change-Id: Id439aef9cab3348171a23378cdd47ede5f4d7288
> > Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630350
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Reviewed-by: Adam Klein <adamk@chromium.org>
> > Commit-Queue: Shu-yu Guo <syg@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#81734}
>
> Bug: v8:12547
> Change-Id: I638304c3d5722c64bd04708ed4cf84863cdebb81
> Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763787
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82278}
Bug: v8:12547
Change-Id: I27c2aeb131f1b68c2240323189db88d552aa92f9
Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3817187
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Owners-Override: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82292}
Avoid terminating from another thread in some thread termination
unit tests.
Change-Id: I0f66e49f1f4e7e3d6ec4c614c2cc1afc9fdb0a22
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3816663
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82284}
... when setting the prototype of TypedArray constructor.
Setting the __proto__ of TypedArray constructor could change TypedArray's
@@species, thus we need to invalidate the @@species protector.
Bug: v8:13110
Change-Id: Ib3b2c88d1136965c221492ff81a26ae69533b356
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3813063
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82282}
This is a reland of commit e2066ff6bf
Changes since revert:
- Rebased against c991852491, which
uses the external pointer table for the WaiterQueueNode stored
in the state field when compressing pointers. This relaxes
the alignment requirement of the state field to be 4-bytes when
compressing pointers.
- Moved the state field into the JSSynchronizationPrimitive base
class, since alignment and padding can now be made simpler.
Original change's description:
> [shared-struct] Add Atomics.Condition
>
> Bug: v8:12547
> Change-Id: Id439aef9cab3348171a23378cdd47ede5f4d7288
> Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630350
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81734}
Bug: v8:12547
Change-Id: I638304c3d5722c64bd04708ed4cf84863cdebb81
Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763787
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82278}
Use a single SBFX instruction for Word64Sar(ChangeInt32ToInt64(x), imm)
when possible.
Using PGO, this improves Speedometer2 by 0.4% on a Cortex-A55 machine,
and 0.27% on a Neoverse-N1 machine.
Change-Id: I6fea5e473f0f0869f8f6cebd9a4e61bb2fc6e9ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807586
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82277}
noextern is the abstract null type for the extern type.
Bug: v8:7748
Change-Id: I03ac0daf3051f479e096f3d05f4fa7cbf03968f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810191
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82276}
nofunc is the abstract null type, the equivalent of none but for the
function type hierarchy.
none and nofunc (and later on noextern) all can only represent a null
value, however their nulls are distinct (as there isn't any subtype
relationship between them).
Bug: v8:7748
Change-Id: Ic5ae502cc21a581ca2e0f5abc46139435d950af9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3805884
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82274}
We should verify the consistency of the objects we produced after deserializing successfully.
Bug: v8:11525
Change-Id: Ieec1aa7112ab6eda0c61a1a9ab78e86ad8352942
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3813061
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82272}
The test-gc cctest loads the WasmCode from the NativeModule and then
executes it. With lazy compilation, the WasmCode object first has to get
generated before it can get loaded.
R=jkummerow@chromium.org
Bug: v8:12852
Change-Id: I83a8a2433ac5d11690c82f07e4ae01ddc979821c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3809811
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82271}
...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}
