A BoundedSize is just a regular size_t when the sandbox is disabled.
However, when the sandbox is enabled, a BoundedLength is guaranteed to
be in the range [0, kMaxSafeBufferSizeForSandbox]. This is (currently)
achieved by storing the length shifted to the left, then right-shifting
it when loading it. This guarantees that the top bits are zero.
BoundedSizes are used to ensure safe access to variable-sized buffers,
in particular ArrayBuffers and their views, located inside the sandbox.
If a full size_t is used to represent their size, it may allow an
attacker to "reach out of" the sandbox address space by setting the
length to a very large value. A BoundedSize prevents this.
Bug: chromium:1360375
Change-Id: I0579693db528af96c41eeaa64bd3ed71266aacd9
Cq-Include-Trybots: luci.v8.try.triggered:v8_linux64_no_sandbox_dbg_ng_triggered
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3876823
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83631}
Wait for TF optimisation to be requested (or to have happened) before
cranking up TF OSR urgency; this prevents us from getting into a
situation where we repeatedly call Maglev code which then OSRs into
TurboFan lots of times before finally tiering up to TurboFan properly.
Since we are waiting for TF optimisation to be requested, we also need a
mechanism to allow TF optimisation to be requested even when Maglev code
has been requested hasn't yet run (for direct Baseline->Turbofan tierup,
since Maglev can't OSR). Do so by re-trying the optimisation check if it
spits out Maglev but Maglev is already requested.
As a drive-by, clean up some naming around OSR code.
Bug: v8:7700
Change-Id: I483a412dd92fe13ee21f8aa46d86572bcf3f8a61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3942385
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83630}
ValueNumberingAssembler is now based on the dominator tree of the
new graph rather than the one of the old graph (since using the old
graph could be invalid, because control flow can change during the
OptimizationPhase).
To do so, the dominator tree of the new graph is now computed on the
fly.
Bug: v8:12783
Change-Id: I2d628b4c0e50931b32e6c0455bf00a119fbf57eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3937978
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83628}
The {validate_functions} parameter of {ModuleDecoder::DecodeSection} is
always false, hence drop it.
R=thibaudm@chromium.org
Bug: v8:13371
Change-Id: I403af4cccaedf758b28bc2304414d60691532489
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3941710
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83626}
The scope prevents recursive garbage collections that may otherwise
trigger through allocations in destructors.
Bug: chromium:1372784
Change-Id: I98525333701551962bbc2a16f8f50eeb637fc03d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3942651
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83625}
Be bug-for-bug (or is it feature-for-feature?) compatible with the
interpreter/baseline interrupt budget updates; in particular, add
support for interrupt budget increases on the non-fallthrough path of
conditional branches.
The approach taken here is to add an "interrupt budget correction" field
to BasicBlockRef, the ref used to represent jump targets. When resolving
jumps (i.e. BasicBlockRefs) targetting a BasicBlock, if those jumps have
an interrupt budget correction, then we insert an
IncreaseInterruptBudget node as the first node in that target BasicBlock
(edge splitting means that we're guaranteed to have only one predecessor
with an interrupt budget correction, since it's only used for
conditional control).
Change-Id: Ie0f160857df89ad38165ff59fd58fc26c5a76dc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3939670
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83623}
BasicBlocks used to be created only once all nodes in the block were
created (to be able to presize the node array). For a while now,
however, nodes have been in a linked list, and the BasicBlock instances
have been created when the logical basic block starts. However, there
are still some vestigial APIs from the old approach, namely that
"finishing" a basic block is "creating" it, and that jumps to a block
are only resolved in this finish (with a distinction between CreateBlock
and FinishBlock since in some cases we don't want to resolve jumps to an
offset).
This CL simplifies this by:
* Removing CreateBlock, and making FinishBlock the only API for
creating the ControlNode and closing the BasicBlock,
* Making `StartNewBlock(int offset)` also resolve jumps to that target
offset,
* Making fallthrough block creation explicit, as opposed to automagic
for conditional blocks on finish,
* Drive-by, removing empty block predecessors since they're not used
ever since empty blocks got register merge states.
Bug: v8:7700
Change-Id: I1162bf79f84fb54f9523ed4c7652d04da32631d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3939669
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83622}
Instead of potentially starting incremental marking when allocating
from the free list, it can be started in the ConcurrentAllocator.
This will make it easier to reuse the ConcurrentAllocator on the main
thread. Also it probably generally makes sense to decouple free list
allocation from incremental marking.
Bug: v8:13375
Change-Id: I660bb0cf6a304eebf82d94bbd582703cd8ce2757
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3942255
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83621}
This is a reland of commit c5e56d450b
No changes since revert. Revert was incorrect in suspecting CL for
GC stress failures.
Original change's description:
> [wasm] Remove field to store "intermediate" error
>
> We used to store the first error during function validation there, and
> then later return it instead of the outer (module-wide) decoding error.
> This is redundant, we can just directly store a function validation
> error in the outer error field.
> This also removes the boolean parameter to {Decoder::FinishDecoding}.
> This was always redundant, since the "intermediate error" was only set
> if function validation was enabled before.
>
> R=jkummerow@chromium.org
>
> Bug: v8:13371
> Change-Id: Ib812d4ba0ea10e9a5dda46cac4e33d427dd9c16c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3942084
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83612}
Bug: v8:13371
Change-Id: If53599a843201f83fb77671d6398e7150632acd8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3943130
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83618}
This reverts commit 4804c4de31.
Reason for revert: GC stress failure:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20gc%20stress/1075/overview
Original change's description:
> [wasm] Allocate feedback vectors on demand
>
> We previously allocated feedback vectors when instantiating the module,
> or when lazily compiling a function. That's not sufficient when there
> are multiple instances of the same NativeModule, or when we eagerly
> tier-down all code for debugging. This patch changes the "get vector from
> instance" sequence at the beginning of every Liftoff function to "get
> or allocate vector"; factored into a builtin call to avoid generating
> more code for every function.
>
> Bug: v8:12852
> Change-Id: I12ab96dc9575f5dff089147af1bf9b280616892d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3939667
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83610}
Bug: v8:12852
Change-Id: I200118185f265da7dd0956bbd5a45a4d40e4bbc0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3943126
Owners-Override: Shu-yu Guo <syg@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83617}
This reverts commit c5e56d450b.
Reason for revert: GC stress failure:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/40769/overview
Original change's description:
> [wasm] Remove field to store "intermediate" error
>
> We used to store the first error during function validation there, and
> then later return it instead of the outer (module-wide) decoding error.
> This is redundant, we can just directly store a function validation
> error in the outer error field.
> This also removes the boolean parameter to {Decoder::FinishDecoding}.
> This was always redundant, since the "intermediate error" was only set
> if function validation was enabled before.
>
> R=jkummerow@chromium.org
>
> Bug: v8:13371
> Change-Id: Ib812d4ba0ea10e9a5dda46cac4e33d427dd9c16c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3942084
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83612}
Bug: v8:13371
Change-Id: Ib8e31d72971b9ca3ced37a8f549c83aa82df29d0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3943124
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Owners-Override: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83616}
The {ModuleDecoderTemplate::DecodeSingleFunction} method is only used
for testing. It's helpful to know that from the code, so add the proper
suffix.
R=jkummerow@chromium.org
Bug: v8:13371
Change-Id: Id36a37272ef829aaf6d551c9334953c612dce2ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3942086
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83615}
We used to store the first error during function validation there, and
then later return it instead of the outer (module-wide) decoding error.
This is redundant, we can just directly store a function validation
error in the outer error field.
This also removes the boolean parameter to {Decoder::FinishDecoding}.
This was always redundant, since the "intermediate error" was only set
if function validation was enabled before.
R=jkummerow@chromium.org
Bug: v8:13371
Change-Id: Ib812d4ba0ea10e9a5dda46cac4e33d427dd9c16c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3942084
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83612}
We previously allocated feedback vectors when instantiating the module,
or when lazily compiling a function. That's not sufficient when there
are multiple instances of the same NativeModule, or when we eagerly
tier-down all code for debugging. This patch changes the "get vector from
instance" sequence at the beginning of every Liftoff function to "get
or allocate vector"; factored into a builtin call to avoid generating
more code for every function.
Bug: v8:12852
Change-Id: I12ab96dc9575f5dff089147af1bf9b280616892d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3939667
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83610}
Visit stack & regular roots of all clients in the shared space
isolate. The ClientRootVisitor filters out all roots not pointing
into the shared heap. This way the regular root visitor doesn't need
to handle the case of roots pointing into client-local pointers.
Bug: v8:13267
Change-Id: I7b602b43df0ddff490142a1af2b804a9ca5edb83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3941886
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83606}
This CL implements support for clamping floating point to integer
values when [Clamp] annotation is passed to a fast API call argument.
It uses min(max(value, lower_bound), upper_bound) as specified by
https://webidl.spec.whatwg.org/#es-integer-types-abstract-ops, step 7.
Bug: chromium:1052746
Change-Id: Ie12c0d98076863ac00aead9319f5770d7028773d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3749205
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83605}
The functions are useful for debuggability. It's convenient to always
have them present.
Change-Id: I805c2fe1dc96aabea504241f06dc5a1e2b435099
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3932179
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83604}
This CL introduces statement positions before the right-hand side of
comma expressions, in order to align the stepping behavior (and also
generally the breakpoint behavior) around semicolon (;) and comma (,)
separated expressions.
The motivation here is that left-hand sides of comma expressions are
evaluated purely for their side-effects and as such, they aren't
really any different from statements from a developers perspective.
And more importantly, minifiers (like UglifyJS, terser, or esbuild)
by default turn statement expression lists into comma-separated
expressions, thus implicitly changing the stepping behavior in ways
that are difficult to understand for developers.
Doc: http://go/chrome-devtools:comma-stepping-proposal
Demo: https://devtools-dbg-stories.netlify.app/crbug-1370200.html
Video: https://i.imgur.com/5WC03wF.gif
Fixed: chromium:1370200
Change-Id: I38f288d964bc992d1de0dce2ed2becd4220793df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3934288
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83599}
The process of checking a function body for validity is called
"validation" in the spec, hence also use this term in the code instead
of "verification".
R=jkummerow@chromium.org
Bug: v8:13371
Change-Id: Icef65282f829f600975ae4b10eb0847ba75e7ae3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3941887
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83598}
These can cause deopts due to dependency invalidation.
Bug: v8:7700
Change-Id: I473e48bf4c803a0eedade6a149dad20133e517f6
Fixed: v8:13325
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3937468
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83595}
The CL makes Oilpan use the same data-structure (two-layer bitmap) as V8
uses for the remembered set.
Bug: chromium:1029379
Change-Id: I1213d3ae06da5e85466430875378e3b8dfdee16e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3701592
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83594}
This regresses performance a little too much. We can still reconsider
later what we want to do, and how important memory is.
Bug: v8:7700
Change-Id: Iea4a78ec0d7b45dbfa8ba7a41903612da8b85db9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3941884
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83592}
This CL adds a DCHECK to SFI::UpdateFromFunctionLiteralForLiveEdit
making sure that when we update the ScopeInfo object on an SFI that
they are equivalent modulo position info.
We also skip checking the `SourceTextModuleInfo` as it's `Equals`
implementation checks that different `SourceTextModuleInfo` instances
point to the same FixedArrays. This does not hold for live edited
modules.
The CL also adds the missing handling for Oddballs in
ScopeInfo::Equals. The inferred function name can be `undefined`.
R=leszeks@chromium.org
Bug: chromium:1363561
Change-Id: Ie28272f2fed149921c0acc8e37d9bbdfb1c92aed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3937963
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83591}
This is a reland of commit b41333125d
The initial CL wrongly assumed that the whole scope chain stays
intact. The reland fixes this by aborting a DCHECK if we didn't
find the right ScopeInfo.
Original change's description:
> [liveedit] Pass outer ScopeInfo when live editing sloppy eval'd scripts
>
> The CL https://crrev.com/c/3932724 changed LiveEdit to replace the
> ScopeInfo object of "unchanged" SFIs instead of updating the position
> info in place. As a side-effect, we no longer set the outer ScopeInfo
> on sloppy EVAL_SCOPEs.
>
> This CL fixes that by properly passing the outer ScopeInfo along to
> the compiler. It's also necessary to pass the outer ScopeInfo to the
> reparse of the original script. Otherwise we'd get false positives in
> the logic that detects outer scope changes for unchanged functions.
>
> R=leszeks@chromium.org
>
> Bug: chromium:1363561
> Change-Id: Ia0bd8363cd835d7c7ffdc1d157c6657e6e2275c3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3937802
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83584}
Bug: chromium:1363561
Change-Id: I4a3e8eed5cea86526e131323e6b24ed90b8cdde9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3938038
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83590}
This reverts commit b41333125d.
Reason for revert: gc-stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/40753/overview
Original change's description:
> [liveedit] Pass outer ScopeInfo when live editing sloppy eval'd scripts
>
> The CL https://crrev.com/c/3932724 changed LiveEdit to replace the
> ScopeInfo object of "unchanged" SFIs instead of updating the position
> info in place. As a side-effect, we no longer set the outer ScopeInfo
> on sloppy EVAL_SCOPEs.
>
> This CL fixes that by properly passing the outer ScopeInfo along to
> the compiler. It's also necessary to pass the outer ScopeInfo to the
> reparse of the original script. Otherwise we'd get false positives in
> the logic that detects outer scope changes for unchanged functions.
>
> R=leszeks@chromium.org
>
> Bug: chromium:1363561
> Change-Id: Ia0bd8363cd835d7c7ffdc1d157c6657e6e2275c3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3937802
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83584}
Bug: chromium:1363561
Change-Id: I58cb5356ca2d13a4fc30dfabaa1c8fc7214f14b9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3937977
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@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@{#83585}
The CL https://crrev.com/c/3932724 changed LiveEdit to replace the
ScopeInfo object of "unchanged" SFIs instead of updating the position
info in place. As a side-effect, we no longer set the outer ScopeInfo
on sloppy EVAL_SCOPEs.
This CL fixes that by properly passing the outer ScopeInfo along to
the compiler. It's also necessary to pass the outer ScopeInfo to the
reparse of the original script. Otherwise we'd get false positives in
the logic that detects outer scope changes for unchanged functions.
R=leszeks@chromium.org
Bug: chromium:1363561
Change-Id: Ia0bd8363cd835d7c7ffdc1d157c6657e6e2275c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3937802
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83584}
This rolls copyright header updates and applies similar updates to local
files.
Bug: chromium:1098010
Change-Id: I5d2cd730d7c3af51fc2cdfbd0abfb91b8de88995
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3939044
Auto-Submit: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83583}
Port 222007bc11
Port 78570f7826
Bug: v8:9407
Change-Id: I5de127dad747bd94b7129476acd67cb2ce8af09d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3940601
Auto-Submit: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#83582}
