- 11 Dec, 2020 22 commits
-
-
Junliang Yan authored
Change-Id: I083a15e0a25668e149f832477c9bef0963993696 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2587353Reviewed-by:
Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#71725}
-
Junliang Yan authored
Change-Id: I59c905182294dc4e8fb8caf03f10ea66d332e034 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2586153Reviewed-by:
-
Milad Fa authored
Change-Id: Id9a8f9d7a7ccf7dc85a140ed3da30f429fc073ba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2587008Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#71723}
-
Milad Fa authored
PPC has a set of 64 Vector Registers called VSX. The lower 32 of them are shared with Floating Point register (only 64 bit of the registers are used for FP operations). The upper 32 registers are VR registers which are only used for VMX Vector operations. VSX Vector operations have the option to use the lower 32 or upper 32 registers using the TX bit set on the instructions. VMX operations only use the upper 32 registers. In V8 we always set the VSX TX bit to "1" to make sure all the vector operations take place on the upper 32 registers. Change-Id: Ib3ea03254cbdc9547c3b698fe19c0c6b28138741 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2585260 Commit-Queue: Milad Fa <mfarazma@redhat.com> Reviewed-by:
-
Jakob Kummerow authored
This flag disables the implicit fallback to Turbofan when Liftoff bails out due to an unsupported instruction/type. Instead, Liftoff bailouts are treated as fatal errors. This is meant for testing; it is not (yet?) a configuration we support in production. Change-Id: I04e2045f1976e202e65da0ba8e8d660c47859bf4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584949Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#71721}
-
Junliang Yan authored
Change-Id: I6d7e263b84d6871cb13cb01b2b51299b9249d961 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2586994Reviewed-by:
-
Clemens Backes authored
The rest of the code base was already migrated last year in https://crrev.com/c/1631409. In the API we have to be more careful to not break embedders. According to the standard there is no semantic difference between typedef and using ([decl.typedef#2]): A typedef-name can also be introduced by an alias-declaration. The identifier following the using keyword becomes a typedef-name and the optional attribute-specifier-seq following the identifier appertains to that typedef-name. Such a typedef-name has the same semantics as if it were introduced by the typedef specifier. Thus this CL replaces all typedefs in include/v8.h by the equivalent using declaration. This improves readability, especially for function pointer types. R=ulan@chromium.org CC=leszeks@chromium.org Bug: v8:11074 Change-Id: Id917b6aa5c8cd289c60bda5da1e3667e747936e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563880 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#71719}
-
Clemens Backes authored
The name has very few uses. I found at least one where the current value does not make sense (on js-to-wasm wrappers in profiling), but I found zero uses that were actually useful. Hence this CL removes the name, i.e. just sets none on wasm scripts. R=thibaudm@chromium.org, yangguo@chromium.org Bug: chromium:1125986 Change-Id: I2f793986a3da905980132cd09349dd6a1d787957 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584245 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#71718}
-
Junliang Yan authored
Change-Id: I9761b80f32beeb53e466fc67ee1c535075e4225c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2586993Reviewed-by:
-
Nico Hartmann authored
This CL moves SharedFunctionInfo and BytecodeArray to the kNeverSerialized classes, making them directly accessible from the background thread. To resolve the dependence on HeapNumber and BigInt objects stored in the BytecodeArray's constant pool, this CL introduces a new ObjectDataKind::kPossiblyBackgroundSerializedHeapObject, which allows for objects to be serialized lazily from the background thread where we know that this is safe (e.g. because they are constant). BigInt and HeapNumber are the first members of this new group of objects. Bug: v8:7790 Change-Id: I1d962d1cb7c36cc3f5baeb9603d5298f32af3363 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567705Reviewed-by:
Georg Neis (ooo until January 5) <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#71716}
-
Peter Marshall authored
I think this was likely fixed by one of the other bugfixes in the meantime. It doesn't flake with 50k runs locally. Fixed: v8:2008 Change-Id: I9e6f1e7f75cf20c52d49937d980aafacaa23b401 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584945Reviewed-by:
-
Thibaud Michaud authored
The issue is with this pattern, assuming disjoint uses for all vregs: phi: v1 = v0 ... phi: v2 = v0 ... phi: v3 = v0 ... ... phi: vN = v0 ... For every phi, BuildBundles proceeds as follows: - Create a new bundle for the output - Merge the input bundle into the output bundle Since the bundle gets bigger at every iteration, the merges become more and more expensive and consume Zone memory that is immediately thrown away at the next iteration. A simple fix is to check the size of the bundles before merging and always copy the smallest one into the biggest. In the pattern above this should always copy the single-range output bundle into the large input bundle. R=sigurds@chromium.org Bug: v8:11237 Change-Id: I6ad9152035da698d94b02b5b41802545ba149307 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584879Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#71714}
-
Manos Koukoutos authored
When Liftoff bails out, the function ExecuteLiftoffCompilation performs an early return before updating the "counters" data structure with the bailout reason. The early return was introduced in https://chromium-review.googlesource.com/c/v8/v8/+/2423710. We should just drop it again, as there is another "if (did_bailout()) return" right after updating the counters. Bug: v8:11259 Change-Id: Ia7f72c3a7eda4252a5a4450646427edb26130996 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584880Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#71713}
-
Omer Katz authored
The gc_in_progress flag was reset to false only after sweeping was done. As a result, if we call CollectGarbage during an incremental GC and after marking has finished, the we will observe that a gc is still in progress but will not have a marker and crash. The immediate solution is to move resetting the gc_in_progress flag such that it indicates whether we didn't have the atomic pause yet. That means we could have gc_in_progress==false and incremental sweeping still running, which semantically negates the meaning of gc_in_progress. Observing that gc_in_progress essentially becomes equivalent to having a marker, this CL removes the gc_in_progress flag and replaces checks on it with checks on marker. Bug: chromium:1156170 Change-Id: Ic4b441ec248b5f7e222e988870e46d5166dd4dcc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584875 Commit-Queue: Omer Katz <omerkatz@chromium.org> Auto-Submit: Omer Katz <omerkatz@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#71712}
-
Liviu Rau authored
Using the config of one of the builders that catched the chromium:1138115 issue; compile only. Bug: chromium:1142484 Change-Id: I4ad19a7c32819a3a8306fa169d3c8ec0ffb47a8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584874 Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#71711}
-
Anna Henningsen authored
Add a method that returns the microtask queue that is being used by the `v8::Context`. This is helpful in non-monolithic embedders like Node.js, which accept Contexts created by its own embedders like Electron, or for native Node.js addons. In particular, it enables: 1. Making sure that “nested” `Context`s use the correct microtask queue, i.e. the one from the outer Context. 2. Enqueueing microtasks into the correct microtask queue. Previously, these things only worked when the microtask queue for a given Context was the Isolate’s default queue. As an alternative, I considered adding a way to make new `Context`s inherit the queue from the `Context` that was entered at the time of their creation, but that seemed a bit more “magic”, less flexible, and didn’t take care of concern 2 listed above. Change-Id: I15ed796df90f23c97a545a8e1b30a3bf4a5c4320 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2579914Reviewed-by:
-
Mythri A authored
next_enumeration_index is the next free index available to store a property. ObjectDescriptor tracks this field while instantiating the literal and updates the next_enumeration_index when finalizing the instantiation. When adding new properties (named / computed) we were updating this value to the current value that is being used instead of next free index. This cl fixes it. Bug: chromium:1152231 Change-Id: Ica8c36dcabf035db559e29d4573ecd5e53d6062a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2577463 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71709}
-
Zhi An Ng authored
movd/movq moves from/to 32/64 bit operand to xmm, the disasm was incorrect printing both operands as xmm. Was: "movd xmm2,xmm10" Now: "movd xmm2,r10" Change-Id: I4061257da763efd3493a3fd5875dc116296e1737 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2585258Reviewed-by:
-
Michael Achenbach authored
Change-Id: Ibaea56e50635dac7fe43bd7599ebcf92692fbfec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584870Reviewed-by:
-
Michael Achenbach authored
Change-Id: If3c7e11516c72091b280dbeced3df0d37c5aaa2b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584869Reviewed-by:
-
Zhi An Ng authored
Implementation is almost identical to x64, except that in the instruction-selector, for AVX, we allow the second operand to be a slot, and so we use InputOperand in the codegen. Bug: v8:11008 Change-Id: I5b5ea4b5058dc0bf5ff1c24a67f9b787c5312106 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2576887Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71705}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/68a1580..026aa68 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/86a7f72..ea9f1f7 Rolling v8/third_party/aemu-linux-x64: FZmiNfUmb6lJR28DxZkS03xoY4oJh4177LjCbVwbpCMC..5qqsaI1HWopoPDYdsXSJnZ-4w5bARXjJgFX_oohbDqIC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/4565794..d5e2194 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/99b0e4a..c94b21d TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I9dc4a6bf1a806397c96d22b8125c79bccd066b4f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2586011Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#71704}
-
- 10 Dec, 2020 18 commits
-
-
Bill Budge authored
This reverts commit cddaf66c. Reason for revert: Multiple fuzzer failures TBR=neis@chromium.org,ahaas@chromium.org Original change's description: > [compiler][wasm] Align Frame slots to value size > > - Adds an AlignedSlotAllocator class and tests, to unify slot > allocation. This attempts to use alignment holes for smaller > values. > - Reworks Frame to use the new allocator for stack slots. > - Reworks LinkageAllocator to use the new allocator for stack > slots and for ARMv7 FP register aliasing. > - Fixes the RegisterAllocator to align spill slots. > - Fixes InstructionSelector to align spill slots. > > Bug: v8:9198 > > Change-Id: Ida148db428be89ef95de748ec5fc0e7b0358f523 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512840 > Commit-Queue: Bill Budge <bbudge@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71644} TBR=bbudge@chromium.org,neis@chromium.org,ahaas@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9198 Change-Id: Ib26d016df6f30f333d30b5ac14eed9630bba8252 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584200 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
-
Frank Tang authored
cl for chrome/src/DEPS in https://chromium-review.googlesource.com/c/chromium/src/+/2582536 Bug: v8:10447 Change-Id: I28452cab64f000aa8cc466290ffcc97aa0b41f78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2583189 Commit-Queue: Shu-yu Guo <syg@chromium.org> Auto-Submit: Frank Tang <ftang@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#71702}
-
Junliang Yan authored
a few unused functions Drive-By: Also clean up LoadSimd128 as LoadV128 and remove Change-Id: I4cdee0fcb1e153309492026b4334af27afba7ec1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584442 Commit-Queue: Junliang Yan <junyan@redhat.com> Reviewed-by:
-
Etienne Pierre-doray authored
Follow up on https://chromium-review.googlesource.com/c/v8/v8/+/2510969 Now that gin implements the new version: https://chromium-review.googlesource.com/c/chromium/src/+/2566052 These can be deprecated. Change-Id: Ie1e5448655e40eb3c11089f59510f269a9873e66 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566430Reviewed-by:
-
cjihrig authored
This commit updates the gen-postmortem-metadaa.py script to incorporate changes in V8 8.5. This removes the need to float a patch to the script in Node.js. Change-Id: I6532495bee906f51eb2b773ec38ff0a6e404dafe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2582705Reviewed-by:
-
Omer Katz authored
Add fields to HeapOptions to denote on heap creation that the heap does not support incremental/concurrent marking/sweeping. This only applies to standalone heaps. When triggering a GC (either explicitly or by the heap growing heuristics), the given config is limited to not trigger unsupported marking/sweeping types. Bug: chromium:1156170 Change-Id: Id7b5cf82962e7c40920f942df9415d798e2b6686 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581961 Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by:
-
Andreas Haas authored
R=ecmziegler@chromium.org Change-Id: I35b87585a1fab35fd2e0265d0cf74a092521a872 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584244Reviewed-by:
Emanuel Ziegler <ecmziegler@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#71697}
-
Clemens Backes authored
The NativeModule should not die before the WasmEngine, since state owned by the engine will still be accessed in the destructor of the NativeModule. This CL ensures that by moving the OperationsBarrier from the CompilationStateImpl to the NativeModule. R=thibaudm@chromium.org, etiennep@chromium.org Bug: v8:11250, v8:11243 Change-Id: Ic4d69222e9e6076578c35986b0051817dbd8dbef Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581959 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Clemens Backes authored
So far we reported the script ID, but DevTools ignores that and uses the source url instead. That url was just set to "wasm ", which the frontend couldn't make any sense of. This CL fixes this by passing the source URL to the code create event, and also setting the position of the code inside the script (i.e. wasm module). R=thibaudm@chromium.org, petermarshall@chromium.org Bug: chromium:1125986 Change-Id: Ic41dcd2768c60fd6748468d3a89fc4ffccb35932 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581543 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#71695}
-
Andreas Haas authored
NOTRY=true R=thibaudm@chromium.org CC=clemensb@chromium.org Change-Id: I387421edeb1404479e76aaae6f73c6b956672cf5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581966Reviewed-by:
-
Andreas Haas authored
NOTRY=true R=manoskouk@chromium.org Bug: v8:9495 Change-Id: I72142c4992e969852341b49a8e5628b53ec1d5b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581965Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#71693}
-
Peter Marshall authored
Function prototypes can be lazily allocated. This means they go into the temporary objects set that debug-eval uses to figure out if a write will be side-effect free. We were incorrectly classifying writes to function prototypes as side-effect free because the prototype happened to be lazily allocated when we first accessed it during debug-eval, but was actually reachable from the function (not allocated temporarily). To do this we introduced a way to temporarily turn off the temporary object tracking, and we use it when lazily allocating function prototypes. This could mean that we incorrectly report side-effects when writing to function prototypes for functions which were themselves created during debug-eval side-effect free mode. However, it's unclear if this is a problem, because function declarations set global variables which would already throw due to side-effects. Bug: chromium:1154193 Change-Id: I444a673662095f6deabaafdce3cdf3d86b71446d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581968Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#71692}
-
Frank Tang authored
This is a reland of c9c3ec4c Original change's description: > [intl] Clean up intl_segmenter flag > > Intl.Segmenter shipped in m87 and launched. > > Bug: v8:11225 > Change-Id: I4213e261e1aea717c1281f19785a8c29ff1bbd8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2570461 > Commit-Queue: Frank Tang <ftang@chromium.org> > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71653} Bug: v8:11225, v8:11240 Change-Id: Ibded9038671862d90206d328f8a12db51c40e63c Cq-Include-Trybots: luci.v8.try:v8_linux64_gc_stress_custom_snapshot_dbg_ng,v8_linux_arm64_gc_stress_dbg_ng,v8_linux_gc_stress_dbg_ng,v8_mac64_gc_stress_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2579043 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
-
Peter Marshall authored
Bug: v8:10996 Change-Id: I90a1e7bb8b5b961c5d22f53cd1319f25194c66bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581967 Auto-Submit: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
-
LiuYu authored
Bug: v8:11215 Change-Id: Ib608e580f1b460640d19b6dc6acb09f2fad289b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2578654 Auto-Submit: Liu yu <liuyu@loongson.cn> Reviewed-by:
Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71689}
-
Zhi An Ng authored
Add new macro-assembler instructions that can handle both AVX and SSE. In the SSE case it checks that dst == src1. (This is different from that the AvxHelper does, which passes dst as the first operand to AVX instructions.) Sorted SSSE3_INSTRUCTION_LIST by instruction code. Header additions are added by clangd, we were already using something from those headers via transitive includes, adding them explicitly gets us closer to IWYU. Codegen sequences are from https://github.com/WebAssembly/simd/pull/380 and also https://github.com/WebAssembly/simd/pull/380#issuecomment-707440671. Bug: v8:11086 Change-Id: I4c04f836e471ed8b00f9ff1a1b2e6348a593d4de Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2578797 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Zhi An Ng authored
SSE2_INSTRUCTION_LIST is unchanged, just sorting by the opcode. Added ucomisd to the SSE2_UNOP_INSTRUCTION_LIST. The disassembly for these instructions were mixed with some other special cases, extracted those out into their own clauses. Bug: v8:11074 Change-Id: I34871d4bff79d714c006eb5fd96225f7589cf115 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2576886 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Zhi An Ng authored
Bug: v8:11008 Change-Id: Ic72e71eb10a5b47c97467bf6d25e55d20425273a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575784Reviewed-by:
-
