deps: update V8 to 15.2 - #65161
Open
targos wants to merge 39 commits into
Open
deps: update V8 to 15.2#65161targos wants to merge 39 commits into
targos wants to merge 39 commits into
Conversation
Collaborator
|
Review requested:
|
nodejs-github-bot
added
build
Member
Author
|
I guess this is blocked by #64408 (https://github.com/nodejs/node/actions/runs/31307061482/job/93228984418?pr=65161) |
Member
|
Uploaded https://chromium-review.googlesource.com/c/v8/v8/+/8223266 to fix the Linux AArch64 build (haven't tested on real Linux AArch64 yet, but that's what the error message suggests) |
hubot
pushed a commit
to v8/v8
that referenced
this pull request
Aug 13, 2026
GCC requires SVE enabled for the entire translation unit and does not expose raw __builtin_sve_* builtins on a per-function basis. Fallback to Neon if it's not built by Clang. Refs: nodejs/node#65161 Change-Id: I53a06fcf8f901ae0347044c6999463ce99215c45 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8223266 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#109230}
targos
pushed a commit
to targos/node
that referenced
this pull request
Aug 13, 2026
Original commit message:
[simd] Disable SVE implementation of array search for GCC
GCC requires SVE enabled for the entire translation unit and does
not expose raw __builtin_sve_* builtins on a per-function basis.
Fallback to Neon if it's not built by Clang.
Refs: nodejs#65161
Change-Id: I53a06fcf8f901ae0347044c6999463ce99215c45
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8223266
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#109230}
Refs: v8/v8@68cf9ec
Member
|
FWIW https://chromium-review.googlesource.com/c/v8/v8/+/8236132 was opened by @sravani1510 to address the AIX build failure that is occurring on our V8 nightly builds. |
Member
Author
|
@nodejs/platform-windows We're hitting a weird error on Windows: https://github.com/nodejs/node/actions/runs/31699320590/job/94444346312?pr=65161 This wrong path doesn't exist in the code. |
Member
Author
|
@legendecas Can you help with the perfetto build? |
Member
|
Fixed the perfetto build. But I think the CI is failing for tests in large pages. Likely not related. |
Member
Author
|
Thanks. Summary of the remaining issues in GitHub CI: I'll start a Jenkins CI for more coverage. |
Collaborator
Collaborator
Collaborator
Member
Been talking to @miladfarca about this: The Linux ppc64le and s390x machines being tested on have 8GB RAM and this test is allocating 16GB. |
Contributor
|
Patched it here: https://crrev.com/c/8252113 |
This was referenced Aug 18, 2026
Member
|
For the SEA test failures: they should not have run in the first place. #63751 should fix it. |
Member
|
This should fix the alpine failures https://chromium-review.googlesource.com/c/v8/v8/+/8254825 |
hubot
pushed a commit
to v8/v8
that referenced
this pull request
Aug 20, 2026
For most libcs, pthread_getattr_np() returns the the stack reserved limit on the main thread, but musl only returns the current high-water mark at the time of the call. There's no macro to detect musl, so just fallback to the conservative stack limit in cases where the libc is not one that is known to work. Refs: nodejs/node#65161 Change-Id: Ie2b51269b9e8d2d3451d5d68ad1a233d396af935 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8254825 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#109406}
joyeecheung
added a commit
to targos/node
that referenced
this pull request
Aug 21, 2026
Original commit message:
[simd] Disable SVE implementation of array search for GCC
GCC requires SVE enabled for the entire translation unit and does
not expose raw __builtin_sve_* builtins on a per-function basis.
Fallback to Neon if it's not built by Clang.
Refs: nodejs#65161
Change-Id: I53a06fcf8f901ae0347044c6999463ce99215c45
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8223266
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#109230}
Refs: v8/v8@68cf9ec
Co-Authored-By: Joyee Cheung <joyeec9h3@gmail.com> Signed-Off-By: Michaël Zasso <targos@protonmail.com> Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Signed-Off-By: Michaël Zasso <targos@protonmail.com> Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Co-Authored-By: Joyee Cheung <joyeec9h3@gmail.com> Signed-Off-By: Michaël Zasso <targos@protonmail.com> Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Signed-Off-By: Michaël Zasso <targos@protonmail.com> Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Post-mortem libraries should use v8's debug_helper library instead. Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
- Set/GetPrototype - Holder Co-Authored-by: Joyee Cheung <joyeec9h3@gmail.com> Signed-Off-By: Michaël Zasso <targos@protonmail.com> Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Signed-Off-By: Michaël Zasso <targos@protonmail.com> Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Signed-Off-By: Michaël Zasso <targos@protonmail.com> Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
ICU_UTIL_DATA_SHARED had been removed since https://crrev.com/c/1513615, but Node.js still defined it and relied on the removed path on Windows, so the ICU initialization in mksnapshot had been silently failing since then. https://crrev.com/c/7679153 made the failure visible so the build started breaking on Windows. Fix it by always using ICU_UTIL_DATA_STATIC since we already compile the ICU data statically in. Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
V8 bumped its wire-format version from 0x0f to 0x10. Update the expected hex in test-v8-serdes, and derive the v8 header bytes dynamically in test-runner-v8-deserializer so it tracks future bumps automatically. Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
V8 no longer supports JSON.parse on worker isolates while the shared string table is enabled. Since --harmony-struct enables that table and Node workers parse process.config during bootstrap, use direct MessageChannel instead of a worker. Signed-Off-By: Michaël Zasso <targos@protonmail.com> Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Signed-off-by: Chengzhong Wu <cwu631@bloomberg.net> Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Original commit message:
[platform][posix] Fallback to conservative stack limit on musl
For most libcs, pthread_getattr_np() returns the the stack reserved
limit on the main thread, but musl only returns the current high-water
mark at the time of the call. There's no macro to detect musl, so just
fallback to the conservative stack limit in cases where the libc is
not one that is known to work.
Refs: nodejs#65161
Change-Id: Ie2b51269b9e8d2d3451d5d68ad1a233d396af935
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8254825
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#109406}
Refs: v8/v8@ba4ef8d
Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Original commit message:
Skip regress-498816446-3 when there is not enough memory
Currently causing a test failure on a machine with 8Gb of memory:
```
regress-498816446-3.js:25: RangeError: Array buffer allocation failed
```
Change-Id: I9e0396445c0b870d0070d666f9d6081b93e80f9c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8252113
Commit-Queue: Milad Farazmand <mfarazma@ibm.com>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#109426}
Refs: v8/v8@811fe8b
Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Signed-off-by: StefanStojanovic <stefan.stojanovic@janeasystems.com> Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Original commit message:
[cleanup] Remove --js-float16array
Remove the --js-float16array flag and incorporate Float16Array into the
standard typed array macros and baseline snapshot unconditionally.
Float16Array has been shipping by default since M138.
Bug: 548385945
TAG=agy
CONV=052f499d-4ee5-4a10-8afd-900ba4a338db
Change-Id: I2c0012158febf422fdc1b866b9414f3f040e83ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8264275
Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org>
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#109335}
Refs: v8/v8@f3d4d45
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: nodejs#65702
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
r-li.patch
Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Original commit message:
AIX: implement Stack::ObtainCurrentThreadStackReservedLimit
Port 5a54f45b671bdf47e083ffbad547713d8bacb28f
AIX lacks `pthread_getattr_np()` so we implement the function using
pthread_getthrds_np() with PTHRDSINFO_QUERY_ALL, consistent with
ObtainCurrentThreadStackStart(). The `__pi_stackaddr` field maps to the
lowest stack address, equivalent to the base returned by
pthread_attr_getstack() on other POSIX platforms.
IT: 145
Change-Id: Ia1a34912630e3128f61fa0fca502429b837d611f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8236132
Reviewed-by: Milad Farazmand <mfarazma@ibm.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@ibm.com>
Cr-Commit-Position: refs/heads/main@{#109640}
Refs: v8/v8@f4221e0
Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Original commit message:
Rewrite simdutf include paths to allow getting it from system
Change-Id: I2b7b4cb452c22ed72e0935662c3c7477954bc205
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8319848
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#109702}
Refs: v8/v8@a0607c5
PR-URL: nodejs#65891
Reviewed-By: Xuguang Mei <meixuguang@gmail.com>
Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Original commit message:
[base] Guard int8_t ReadUnalignedValue overload on Solaris
On Solaris, int8_t is a typedef for char, so this overload collides with
ReadUnalignedValue(const char*) and fails to compile. Guard it with
V8_OS_SOLARIS, as already used elsewhere in the platform code.
Introduced in:
https://chromium-review.googlesource.com/c/v8/v8/+/7900500
Change-Id: I87c65412f412b6cf4de1f53ccaca539c1ce8c033
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8409815
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Joyee Cheung <joyee@igalia.com>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#110014}
Refs: v8/v8@37baecd
Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Original commit message:
Solaris: implement Stack::ObtainCurrentThreadStackReservedLimit
Port 5a54f45b671bdf47e083ffbad547713d8bacb28f
Solaris is excluded from the generic POSIX implementation, so implement
the function using pthread_attr_get_np() and pthread_attr_getstack(),
consistent with ObtainCurrentThreadStackStart(). The base returned by
pthread_attr_getstack() maps to the lowest address of the thread's
reserved stack.
Change-Id: I08a5b4cd80180b04496b22989cb976d1c24ce8e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8413453
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Joyee Cheung <joyee@igalia.com>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#109953}
Refs: v8/v8@315d9c9
Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Original commit message:
[simd] Disable SVE implementation of array search for older ClangCL
The Microsoft C++ ABI mangler in older ClangCL cannot mangle
these built-ins. Disable SVE in this case.
Refs: llvm/llvm-project#196170
Refs: nodejs#65161
Change-Id: I35e49dd4bfc0617bfa31cb7e3af1a475b4fb1bef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8420284
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#109945}
Refs: v8/v8@820f3d7
Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Original commit message:
[cppgc] Use _AddressOfReturnAddress() for StackStartMarker under MSVC
include/cppgc/heap.h is a public header, and since b3cb54c7e65
("[heap] Add StackStartMarker for cppgc") it calls
__builtin_frame_address(0) unconditionally. That builtin does not exist
in MSVC, so any translation unit built with cl.exe that includes the
header (directly or through v8-cppgc.h) fails to compile, even if it
never constructs a StackStartMarker.
Use _AddressOfReturnAddress() when V8_CC_MSVC is set, which is what
base::Stack::GetCurrentStackPosition() already does for the same
purpose, and keep __builtin_frame_address(0) elsewhere.
Bug: none
Change-Id: Icd4c0238cb277c8e1b73454534ffb2519b302ce9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8361192
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Shelley Vohr <shelley.vohr@gmail.com>
Cr-Commit-Position: refs/heads/main@{#109737}
Refs: v8/v8@5404e0f
Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Original commit message:
[stack-traces] Fix overflow in Error.stackTraceLimit trimming
When stack traces are captured for uncaught exceptions (enabled via
Isolate::SetCaptureStackTraceForUncaughtExceptions, e.g. by the
inspector or by Node.js's --trace-uncaught), CaptureAndSetErrorStack
reuses the simple stack trace and trims it to Error.stackTraceLimit.
Error.stackTraceLimit counts frames, but the raw call site data stores
CallSiteInfo::Fields::kCount slots per frame, so the trim multiplied the
limit by kCount: once in the uint32_t comparison against the array
length and once, as int, to compute the new length. GetStackTraceLimit
clamps the limit to [0, INT_MAX], so for very large limits the uint32_t
product can wrap to a value below the array length. The trim branch is
then taken although the limit exceeds the number of captured frames,
and the int multiplication of the new length overflows.
On main (kCount == 5) the product first wraps at 858993460. That limit
trimmed the raw data to 4 slots (no complete frame) and 858993461 to 9
slots (one frame), so error.stack silently lost frames. Infinity, the
value from the Node.js report, is clamped to INT_MAX; its wrapped
product (2147483643) is not below the array length, so on main it does
not take the trim branch and does not reach the signed overflow.
Fix this by comparing the limit with the number of frames in the raw
data (length / kCount), and only multiplying once the limit is known to
be smaller than the frame count. The resulting length is then bounded
by the existing array length and cannot overflow. Behavior for limits
that did not overflow is unchanged, since the raw data length is always
a multiple of kCount.
This regressed with https://crrev.com/c/7673818 (ebd15783b7b,
"[objects]: Defer CallSiteInfo creation"), which switched from one
CallSiteInfo per frame to kCount raw slots per frame.
This is the underlying cause of Node.js issue 66074. The symptom there
differs from main: Node's V8 14.6 backport of that change has
kCount == 6 and uses int for the comparison and for RightTrim, so the
product overflows for limits above 357913941. For many of those,
including Infinity (INT_MAX * 6 wraps to -6), the result is negative
and fails "Check failed: new_capacity > 0." in RightTrim. Comparing in
frames avoids the overflow in both cases.
The new cctest CaptureStackTraceForUncaughtExceptionHugeStackTraceLimit
enables capture for uncaught exceptions and checks that limits of
858993460, 858993461 and Infinity yield the same error.stack as a limit
of 10, and that a limit of 1 still trims to a single frame. 858993460
and 858993461 are the first limits whose product with kCount wraps
around uint32_t; both fail without this change. The new test and the
existing stack trace tests also pass in a UBSan build, with no
diagnostics.
Bug: 565047704
Refs: nodejs#66074
Change-Id: I3422ca1de6a7dd9448c7fd53fb9bc5e40e2a17c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8426465
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: eliau elkouby (אליהו אלקובי) <eliau.elkouby@gmail.com>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#110043}
Refs: v8/v8@786c1c2
Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
When compiling with MSVC STL, the computation in V8 can exceed the default limit of constexpr steps. Increasing it by 4 times to give it more room. Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
Member
|
Trying to test another rebase here: https://ci.nodejs.org/job/node-test-commit/92884/ Upstreaming these (with some modifications) to reduce the churn: |
Collaborator
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs: #64784