- 17 Aug, 2022 3 commits
-
-
Junliang Yan authored
Port 00746406 Original Commit Message: ... 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= LOG=N Change-Id: I9ad83d27fc5b295ca4827e9608d4be10f7b10551 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3831638 Commit-Queue: Milad Farazmand <mfarazma@redhat.com> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Linke <jgruber@chromium.org> Reviewed-by:
Milad Farazmand <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/main@{#82534}
-
Victor Gomes authored
This allows V8 to be compiled without zlib. Currently we use zlib for 3 features: 1. Snapshot compression. The cl asserts v8_snapshot_compression implies v8_use_zlib. 2. Compression of translation arrays (experimental flag). The runtime flag is only enabled if v8_use_zlib. 3. Snapshot checksums. We fallback to a simple Fletcher algorithm if v8_use_zlib is false. Change-Id: If043c3c21bba4d734573d7e1199d3ddf17b84f41 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3833817 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Jakob Linke <jgruber@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#82527}
-
ishell@chromium.org authored
The Code-less builtins mode is still disabled. Bug: v8:11880 Change-Id: I725ae4187bb394f79c69d5d0d971961e3ea406e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827879 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#82520}
-
- 16 Aug, 2022 1 commit
-
-
Samuel Groß authored
This CL replaces the AllocateExternalPointerEntries methods with per-field init_##fieldname methods for every external pointer field. These now initialize the field by allocating the external pointer table entry for it and also set the initial value. This saves one memory write in the typical case (what used to be AllocateExternalPointerEntries followed by a set_##fieldname) and removes some code that can be factored out into the (DECL_)EXTERNAL_POINTER_ACCESSORS macro. Bug: v8:10391 Change-Id: Iac937316322910de0a8bb99b33592eca8c57a4a6 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810344Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Linke <jgruber@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/main@{#82482}
-
- 10 Aug, 2022 1 commit
-
-
ishell@chromium.org authored
... 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/+/3820063Reviewed-by:
Jakob Linke <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#82330}
-
- 09 Aug, 2022 1 commit
-
-
Samuel Groß authored
JSArrayBuffer::Setup may trigger GC during PostProcessNewJSReceiver. This is Ok if we drop the raw_obj parameter and instead always reference the object through a Handle. Bug: v8:13121 Change-Id: I70361b16a48599ff83094d11008f6288a1402c7f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810342 Auto-Submit: Samuel Groß <saelo@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#82289}
-
- 08 Aug, 2022 2 commits
-
-
ishell@chromium.org authored
... - 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/+/3811287Reviewed-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}
-
jameslahm authored
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/+/3813068Reviewed-by:
Jakob Linke <jgruber@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Cr-Commit-Position: refs/heads/main@{#82254}
-
- 04 Aug, 2022 2 commits
-
-
Dominik Inführ authored
Pass WriteBarrierMode to the code object write barrier and DCHECK WriteBarrier::IsRequired when using SKIP_WRITE_BARRIER. Bug: v8:11708 Change-Id: I457d0fa07e830d6831fb95a4ae9311f6066215e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810171Reviewed-by:
Jakob Linke <jgruber@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#82201}
-
Lu Yahan authored
This is a reland of commit 491de34b 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}
-
- 03 Aug, 2022 1 commit
-
-
Lu Yahan authored
This reverts commit 491de34b. Reason for revert: Lose co-authors information 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: I6abea32c8ea43b080a938782dc643c97a123f1d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3803994Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
ji qiu <qiuji@iscas.ac.cn> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Yahan Lu <yahan@iscas.ac.cn> Cr-Commit-Position: refs/heads/main@{#82163}
-
- 02 Aug, 2022 1 commit
-
-
Pan, Tao authored
We record Sparkplug compiled into SFI which will be saved in disk cache, once deserializes SFI from disk cache, and the SFI was Sparkplug compiled, we trigger concurrent batch Sparkplug compilation, and directly allocate feedback vector on the first call. This CL can improve Speedometer2 by +2%. Change-Id: I89b0ffc6d7a107a1b8c131529e02cd7eb2890888 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3725612Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Tao Pan <tao.pan@intel.com> Cr-Commit-Position: refs/heads/main@{#82122}
-
- 29 Jul, 2022 2 commits
-
-
Lei Zhang authored
In https://crrev.com/c/3764190, V8_COMPILER_IS_MSVC gets used before it is defined, so it has no effect. Move the V8_COMPILER_IS_MSVC define up to fix this. Change-Id: I94c63ad2a8a7555c85730792c1f91e1285a9b77f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3774095 Commit-Queue: Lei Zhang <thestig@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#82090}
-
Lu Yahan authored
This very large changeset adds support for RISCV32. Bug: v8:13025 Change-Id: Ieacc857131e6620f0fcfd7daa88a0f8d77056aa9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3736732Reviewed-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}
-
- 28 Jul, 2022 2 commits
-
-
Seth Brenith authored
This is a reland of commit e895b7af 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/+/3787266Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#82045}
-
Clemens Backes authored
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/+/3789506Reviewed-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}
-
- 25 Jul, 2022 2 commits
-
-
Deepti Gandluri authored
This reverts commit e895b7af. Reason for revert: TSAN failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/8468/overview Original change's description: > Background merging of deserialized scripts > > Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions > with which an embedder could request that V8 merge newly deserialized > script data into an existing Script from the Isolate's compilation > cache. This change implements those new functions. This functionality is > still disabled by default due to the flag > merge_background_deserialized_script_with_compilation_cache. > > The goal of this new functionality is to reduce memory usage when > multiple frames load the same script with a long delay between (long > enough for the script to have been evicted from Blink's in-memory cache > and for the top-level SharedFunctionInfo to be flushed). In that case, > there are two Script objects for the same script: one which was found in > the Isolate compilation cache (the "old" script), and one which was > recently deserialized (the "new" script). The new script's object graph > is essentially standalone: it may point to internalized strings and > readonly objects such as the empty feedback metadata, but otherwise > it is unconnected to the rest of the heap. The merging logic takes any > useful data from the new script's object graph and attaches it into the > old script's object graph, so that the new Script object and any other > duplicated objects can be discarded. More specifically: > > 1. If the new Script has a SharedFunctionInfo for a particular function > literal, and the old Script does not, then the old Script is updated > to refer to the new SharedFunctionInfo. > 2. If the new Script has a compiled SharedFunctionInfo for a particular > function literal, and the old Script has an uncompiled > SharedFunctionInfo, then the old SharedFunctionInfo is updated to > point to the function_data and feedback_metadata from the new > SharedFunctionInfo. > 3. If any used object from the new object graph points to a > SharedFunctionInfo, where the old object graph contains a matching > SharedFunctionInfo for the same function literal, then that pointer > is updated to point to the old SharedFunctionInfo. > > The document at [0] includes diagrams showing an example merge on a very > small script. > > Steps 1 and 2 above are pretty simple, but step 3 requires walking a > possibly large set of objects, so this new API lets the embedder run > step 3 from a background thread. Steps 1 and 2 are performed later, on > the main thread. > > The next important question is: in what ways can the old script's object > graph be modified during the background execution of step 3, or during > the time after step 3 but before steps 1 and 2? > > A. SharedFunctionInfos can go from compiled to uncompiled due to > flushing. This is okay; the worst outcome is that the function would > need to be compiled again later. Such a risk is already present, > since V8 doesn't keep IsCompiledScopes for every compiled function in > a background-deserialized script. > B. SharedFunctionInfos can go from uncompiled to compiled due to lazy > compilation. This is also okay; the merge completion logic on the > main thread will just keep this lazily compiled data rather than > inserting compiled data from the newly deserialized object graph. > C. SharedFunctionInfos can be cleared from the Script's weak array if > they are no longer referenced. This is mostly okay, because any > SharedFunctionInfo that is needed by the background merge is strongly > referenced and therefore can't be cleared. The only problem arises if > the top-level SharedFunctionInfo gets cleared, so the merge task must > deliberately keep a reference to that one. > D. SharedFunctionInfos can be created if they are needed due to lazy > compilation of a parent function. This change is somewhat troublesome > because it invalidates the background thread's work and requires a > re-traversal on the main thread to update any pointers that should > point to this lazily compiled SharedFunctionInfo. > > At a high level, this change implements three previously unimplemented > functions in BackgroundDeserializeTask (in compiler.cc) and updates one: > > - BackgroundDeserializeTask::SourceTextAvailable, run on the main > thread, checks whether there is a matching Script in the Isolate > compilation cache which doesn't already have a top-level > SharedFunctionInfo. If so, it saves that Script in a persistent > handle. > - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks > whether the persistent handle from the first step exists (a fast > operation which can be called from any thread). > - BackgroundDeserializeTask::MergeWithExistingScript, run on a > background thread, performs step 3 of the merge described above and > generates lists of persistent data describing how the main thread can > complete the merge. > - BackgroundDeserializeTask::Finish is updated to perform the merge > steps 1 and 2 listed above, as well as a possible re-traversal of the > graph if required due to newly created SharedFunctionInfos in the old > Script. > > The merge logic has nothing to do with deserialization, and indeed I > hope to reuse it for background compilation tasks as well, so it is all > contained within a new class BackgroundMergeTask (in compiler.h,cc). It > uses a second class, ForwardPointersVisitor (in compiler.cc) to perform > the object visitation that updates pointers to SharedFunctionInfos. > > [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit > > Bug: v8:12808 > Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/main@{#81941} Bug: v8:12808 Change-Id: I82a080e6287828445293cb6b4b94a5e8f15eb8f3 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787213 Auto-Submit: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Deepti Gandluri <gdeepti@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#81943}
-
Seth Brenith authored
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/+/3739232Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#81941}
-
- 21 Jul, 2022 1 commit
-
-
ishell@chromium.org authored
... in various components. Bug: v8:11880 Change-Id: I1e4411ec38a4b15e505bda35a92987972e89d9d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3777718 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#81863}
-
- 19 Jul, 2022 1 commit
-
-
ishell@chromium.org authored
... when external code space is enabled. Currently this mode is guarded by V8_REMOVE_BUILTINS_CODE_OBJECTS flag which is set to false until Code-less builtins are supported. Drive-by: * remove unnecessary methods from AbstractCode, * avoid CodeDataContainer <-> Code roundtrips when accessing writable state of Code objects via CodeT. Bug: v8:11880 Change-Id: Iae3ff3b2feae68d875cbe9f82a6bb076460dd2f8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769832 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#81814}
-
- 18 Jul, 2022 1 commit
-
-
Lei Zhang authored
This file did not include all the headers it needed, so when https://crrev.com/c/3749178 removed a bunch of headers, the MSVC build broke. Add in the missing header to address the MSVC compiler falure. Change-Id: I646787cfde802d8cabe7d61bac2f2066beaec436 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3764190Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Lei Zhang <thestig@chromium.org> Cr-Commit-Position: refs/heads/main@{#81790}
-
- 15 Jul, 2022 2 commits
-
-
ishell@chromium.org authored
Previously these values weres stored only in the Code object associated with the embedded builtins. Bug: v8:11880 Change-Id: I8adf3f654c5c729a8cb58fc6941999b4c251896a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3764442 Auto-Submit: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#81755}
-
Samuel Groß authored
As sandboxed pointers are now default-enabled when the sandbox is enabled, it is no longer possible to deactivate the sandbox at runtime. This CL therefore removes all the logic that was required to support a sandbox that could be disabled at runtime, moves the initialization of the sandbox into V8::Initialize, and deprecates V8::InitializeSandbox. This change also makes the sandbox initialization deterministic if FLAG_random_seed is supplied. Bug: v8:10391 Change-Id: Ibd49f7c251b7c58c642f18a551ecc2c391740970 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762583Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#81746}
-
- 14 Jul, 2022 1 commit
-
-
Samuel Groß authored
When testing the serializer (e.g. via --stress-snapshot), raw external references (i.e. just raw pointers) can be embedded inside the snapshot. When those pointers are sandboxed, the corresponding external pointer tag also needs to be encoded in the snapshot. This CL adds the necessary logic to support this by introducing new serializer Bytecodes for raw external references and encoding the raw pointers together with the tag. Bug: v8:10391 Change-Id: I7b3710c2144e19f7507e3f6db537d250d102ee28 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762575Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#81723}
-
- 13 Jul, 2022 1 commit
-
-
Shu-yu Guo authored
Bug: v8:13039 Change-Id: I80c9e0ab84437f8e932c13b3cb134b9bdb74c1a7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3759563Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#81696}
-
- 11 Jul, 2022 2 commits
-
-
Samuel Groß authored
There seem to be some issues with sandboxed external references in the serializer which cause the --stress-snapshot mode to fail. This CL changes the serializer to serialize external pointers that are unsandboxed (currently all of them) as "regular" external references, not "sandboxed" ones. This should fix the issues on the bots. Bug: v8:10391 Change-Id: I2f889e1d0aa9c5958d4f4337e114423b650c1bb2 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3755148Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#81643}
-
Samuel Groß authored
This CL does the following: - It enables (i.e. allocates and initializes) the per-Isolate ExternalPointerTable when the sandbox is enabled. - It refactors the list of external pointer tags to mark them as "sandboxed" or "unsandboxed". An unsandboxed external pointer has a null tag. - It changes V8_SANDBOXED_EXTERNAL_POINTERS to now essentially just enable sandboxing for all available tags. - It modifies all low-level external pointer accessors to perform the ExternalPointerLookup only if the tag is non-zero and otherwise treat the slot as containing a raw pointer. This now allows rolling out external pointer sandboxing incrementally (separately for each external pointer type), which will in turn allow for more precise performance measurements of the impact of the sandbox. Note: when an external pointer tag is now marked as sandboxed (and V8_SANDBOXED_EXTERNAL_POINTERS is not enabled), the underlying slots are still 64-bits in size. This simplifies the implementation as we would otherwise need to deal with variably-sized external pointer slots. Local benchmarking suggests that the benefits from 32-bit external pointer slots are insignificant on typical benchmarks, so this should be ok. Drive-by: rename kExternalPointerSize to kExternalPointerSlotSize to make it more clear what it refers to (the on-heap storage size). Also delete CodeStubAssembler::InitializeExternalPointerField as it is not currently used and the implementation is fairly inefficient. Bug: v8:10391 Change-Id: I7c38729c7e9048d737a1a8ced84749f5b1f7feab Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3736447Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#81636}
-
- 07 Jul, 2022 1 commit
-
-
Manos Koukoutos authored
Mostly src/codegen, src/compiler, src/snapshot, src/utils. Bug: v8:13006 Change-Id: I2fb31acc749a7376e6f2a7424ed2e67ff479d971 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3749178 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#81575}
-
- 01 Jul, 2022 1 commit
-
-
ishell@chromium.org authored
Currently serialization of external pointers stored in EmbedderDataArray is not supported but such a functionality was never needed before. Bug: v8:13007, v8:12949 Change-Id: I56dc33592c1410ac9e234c60ef79db92a4e96a0f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3740724 Auto-Submit: Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#81497}
-
- 29 Jun, 2022 1 commit
-
-
Toon Verwaest authored
Change-Id: Ia09e8c4528e59116be39be12d688f5b99a34c8e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3732938Reviewed-by:
Igor Sheludko <ishell@chromium.org> Auto-Submit: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#81437}
-
- 27 Jun, 2022 2 commits
-
-
Samuel Groß authored
The ExternalPointerTags are assumed to be compile-time constants in most cases, so turning them into template parameters enforces that. As decisions such as whether to use the per-isolate or the shared external pointer table are encoded into the tag values, forcing those to be compile-time constants guarantees that the compiler will be able to inline the correct logic when accessing an external pointer. With this, there are now two (high-level) ways of accessing external pointer fields from C++: the Read/WriteExternalPointerField methods which require the ExternalPointerTag to be a template parameter, and the ExternalPointerSlot class which takes the tag as an argument. The latter is for example used for snapshot deserialization and by the garbage collector (more generally, by the ObjectVisitor::VisitExternalPointer method), where the tag is not a compile-time constant. Finally, this CL also introduces a new ExternalPointerHandle type which represents the (opaque) on-heap representation of a reference to an entry in an ExternalPointerTable when sandboxing is enabled. Making this its own type makes the code a bit more readable. Bug: v8:10391 Change-Id: I867b8ce41d15d485f1dc66786f233c710c56afcb Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3720641Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#81402}
-
Samuel Groß authored
It is no longer necessary to postpone the allocation of backing stores to avoid triggering GC. As such, the logic around ArrayBuffer deserialization can be simplified. Bug: v8:10391, v8:11111 Change-Id: I7410392a6e658cd4be77e2192483c6d412b63412 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717982Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#81384}
-
- 24 Jun, 2022 2 commits
-
-
Camillo authored
Unaglined allocations are not fully supported in V8. - Set USE_ALLOCATION_ALIGNMENT_BOOL to false for documentation - Verify HeapObject address alignment requirements with --verify-heap - Move address alignment to right after allocation in the deserializer - Use object_size in the CheckAlignment helper to get a chance to figure out which allocation path we took Bug: chromium:1330861, v8:8875 Change-Id: Iffd02d869923ccec133618250dfefb0480b02741 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717995Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#81358}
-
Samuel Groß authored
When a detached JSDataView is deserialized, it's backing ArrayBuffer backing store is empty (i.e. the EmptyBackingStoreBuffer() pointer). Previously, the JSDataView's data_pointer would then be set to EmptyBackingStoreBuffer() + byte_offset(), which is not a valid backing store pointer as it points outside of the sandbox. Instead, which this CL the data_pointer is now simply set to EmptyBackingStoreBuffer(). Bug: v8:10391 Change-Id: Ic7d144f2f20d5ec99438d2b3bf33735fbf8d5fc6 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717987 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#81348}
-
- 23 Jun, 2022 3 commits
-
-
Shu-yu Guo authored
Bug: v8:12939 Change-Id: I853a718dec39485ae1ab1263e2be8f04567447f1 No-Tree-Checks: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3722455Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Owners-Override: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#81339}
-
Shu-yu Guo authored
SeqStrings have their padding bytes serialized as 0s for deterministic snapshot contents. Currently this is done by mutating the SeqStrings and memsetting their padding bytes to 0 when serializing. This mutation is not threadsafe in the presence of shared strings. This CL removes the mutation by serializing the data and padding payloads separately for SeqStrings. Bug: v8:12939 Change-Id: I58c3ada767ce41e0a874a2d6e6392a86142fa1e1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3715715Reviewed-by:
Patrick Thier <pthier@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#81334}
-
Sunny Sachanandani authored
This reverts commit 83f60359. Reason for revert: RB-Dev crash - crbug.com/1338687 Original change's description: > [snapshot] Turn alignment DCHECKS into CHECKS > > This is a temporary change to get more detailed crash reports for > further investigations. > > Bug: chromium:1330861 > Change-Id: Ifdd8d61692577dffd54d07fadb65575a5c30dcd3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3707592 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/main@{#81262} Bug: chromium:1330861, chromium:1338687 Change-Id: I845aee5cfe02dee399851484d1a72f73dc56f1f4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3718943 Auto-Submit: Sunny Sachanandani <sunnyps@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#81327}
-
- 22 Jun, 2022 2 commits
-
-
Samuel Groß authored
When the sandbox is enabled, an empty ArrayBuffer does not have a nullptr backing store but instead points to a special EmptyBackingStore pseudo-object inside the sandbox. This then requires special handling during deserialization. This CL fixes two cases where this was not done correctly, which caused some crashes when --stress-snapshot is active. Bug: v8:10391 Change-Id: I412adace229b979b317864a3e8c12ed4c601b850 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716480Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#81297}
-
Igor Sheludko authored
This reverts commit 319e747a. Reason for revert: it brought unexpected performance regressions. Original change's description: > [arm64] Increase code alignment to 64 > > This should fix unexpected regressions which occur after builtins > modifications. > > This CL affects alignment of embedded builtins on all configurations > and Code header size only for non-pointer compression configuration. > > Bug: v8:11708 > Change-Id: I8058197c5b768a699e7f52446424013e86203b57 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3700392 > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#81113} Bug: v8:11708 Change-Id: I238e799284d59e80dee244b240fe2a72c33e83b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716485 Auto-Submit: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#81292}
-
- 21 Jun, 2022 1 commit
-
-
Camillo authored
This is a temporary change to get more detailed crash reports for further investigations. Bug: chromium:1330861 Change-Id: Ifdd8d61692577dffd54d07fadb65575a5c30dcd3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3707592Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#81262}
-