Conversation
|
Review requested:
|
|
Compared to version 14.5, there is a new test failure that is not obvious. Local run: |
|
Additionally, snapshot is no longer reproducible: Edit: not macOS-specific: https://github.com/nodejs/node/actions/runs/22221811293/job/64279253109 |
|
Note that this changeset does not compile with GCC <14.1, unless the following patch is applied: diff --git a/deps/v8/src/objects/js-duration-format.cc b/deps/v8/src/objects/js-duration-format.cc
index 41bdbc2cc6..c9ef451713 100644
--- a/deps/v8/src/objects/js-duration-format.cc
+++ b/deps/v8/src/objects/js-duration-format.cc
@@ -807,7 +807,7 @@ void OutputFractional(const char* type, int64_t integer, int32_t powerOfTen,
// Pass in the value as int64_t and ask ICU to scale down.
nfOpts = nfOpts.scale(icu::number::Scale::powerOfTen(-powerOfTen));
- int64_t factor = static_cast<int64_t>(std::powl(10, powerOfTen));
+ int64_t factor = static_cast<int64_t>(std::pow(10.0L, powerOfTen));
int64_t bound = std::numeric_limits<int64_t>::max() / factor - 1;
UErrorCode status = U_ZERO_ERROR;
// Use faster ICU API formatInt if the value fit the precision int64_t, |
FYI @joyeecheung |
|
For what it's worth this branch seems to build ok with a RISC-V cross compiler too 👍🏻 (An experimental platform but I thought I'd mention it anyway ;-) ) |
|
@nodejs/platform-windows Can you please have a look at the Windows build failure? |
|
There's still this REPL strict mode issue: #61898 (comment) @nodejs/repl |
|
And the reproducible snapshot: #61898 (comment) @nodejs/startup (for lack of a more specific team) |
It's not so much a REPL issue as an issue with the VM global sandbox interceptors, introduced as a regression with 113b5cf. Previously, we were simulating CheckContextualStoreToJSGlobalObject-esque behaviour by rejecting interceptions on global proxy properties in strict mode if the receiver was not the global object. Now that we can no longer observe the receiver, that mechanism doesn't exist, and statements like (We should probably have VM tests for this.) |
We will either need to merge (or upstream) this, or change the GCC build requirement to >=14.1. |
|
Would you like to try and upstream it? |
|
It would be easier if someone with existing Chromium contributor status did the honours, I'd rather not jump through the hoops for a one-liner! |
|
Locally this fixes the snapshot reproducibility test for me See diffdiff --git a/deps/v8/src/builtins/builtins-proxy-gen.cc b/deps/v8/src/builtins/builtins-proxy-gen.cc
index 0bc45bac300..f0047f044f2 100644
--- a/deps/v8/src/builtins/builtins-proxy-gen.cc
+++ b/deps/v8/src/builtins/builtins-proxy-gen.cc
@@ -63,6 +63,10 @@ TNode<JSProxy> ProxiesCodeStubAssembler::AllocateProxy(
StoreObjectFieldNoWriteBarrier(proxy, JSProxy::kTargetOffset, target);
StoreObjectFieldNoWriteBarrier(proxy, JSProxy::kHandlerOffset, handler);
StoreObjectFieldNoWriteBarrier(proxy, JSProxy::kFlagsOffset, flags);
+#if TAGGED_SIZE_8_BYTES
+ StoreObjectFieldNoWriteBarrier(proxy, JSProxy::kPaddingOffset,
+ Int32Constant(0));
+#endif
return CAST(proxy);
}
diff --git a/deps/v8/src/heap/factory.cc b/deps/v8/src/heap/factory.cc
index b6f6938450c..e0117df19f9 100644
--- a/deps/v8/src/heap/factory.cc
+++ b/deps/v8/src/heap/factory.cc
@@ -3945,6 +3945,9 @@ Handle<JSProxy> Factory::NewJSProxy(DirectHandle<JSReceiver> target,
result->set_target(*target, SKIP_WRITE_BARRIER);
result->set_handler(*handler, SKIP_WRITE_BARRIER);
result->set_flags(JSProxy::IsRevocableBit::encode(revocable));
+#if TAGGED_SIZE_8_BYTES
+ result->set_padding(0);
+#endif
return handle(result, isolate());
}
Uploaded https://chromium-review.googlesource.com/c/v8/v8/+/7666243 |
Also uploaded https://chromium-review.googlesource.com/c/v8/v8/+/7666244 (IIUC, it was a libstdc++ issue fixed by https://gcc.gnu.org/pipermail/libstdc++/2023-February/055493.html) |
I'll take a look. Thanks for the ping. |
Will look into it. Thanks for the ping. |
So that snapshots with proxies can be reproducible. Refs: nodejs/node#61898 Change-Id: I01fac5e18c73cd482a1ae63750dbadf42a12e08a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7666243 Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#105830}
|
@targos, here is the patch to enable building on Windows: v8-146-fix.patch. Two small changes were needed. |
Original commit message:
Zero-initialize proxy padding
So that snapshots with proxies can be reproducible.
Refs: nodejs#61898
Change-Id: I01fac5e18c73cd482a1ae63750dbadf42a12e08a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7666243
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#105830}
Refs: v8/v8@edeb0a4
|
Thanks @StefanStojanovic and @joyeecheung. I pushed your fixes. Let's see how it goes on GH runners. |
Original commit message:
Mark MemCopyAndSwitchEndianness src input as `const`
Needed after this CL: http://crrev.com/c/7600437
Currently getting the following error:
```
candidate function not viable: no known conversion from 'const unsigned char *' to 'void *'
```
Change-Id: I0c0f065b822e0f95ffd06207d280fc8b7bab4403
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7601332
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@ibm.com>
Cr-Commit-Position: refs/heads/main@{#105413}
Refs: v8/v8@daf4656
Original commit message:
[wasm] Fix S128Const on big endian
Since http://crrev.com/c/2944437 globals are no longer little endian
enforced.
S128Const handling in the initializer needs to take this into account
and byte reverse values which are hard coded in little endian order.
This is currently causing failures on Node.js upstream:
nodejs#59034 (comment)
Change-Id: Ifcc9ade93ee51565ab19b16e9dadf0ff5752f7a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7704213
Commit-Queue: Milad Farazmand <mfarazma@ibm.com>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#106082}
Refs: v8/v8@cf1bce4
PR-URL: nodejs#62449
Refs: v8/v8@cf1bce4
Reviewed-By: Guy Bedford <guybedford@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Original commit message:
[api] Add V8::GetWasmMemoryReservationSizeInBytes()
When the system does not have enough virtual memory for the wasm
cage, installing the trap handler would cause any code allocating
wasm memory to throw. Therefore it's useful for the embedder to
know when the system doesn't have enough virtual address space
to allocate enough wasm cages and in that case, skip the
trap handler installation so that wasm code can at least work
(even not at the maximal performance).
Node.js previously has a command line option
--disable-wasm-trap-handler to fully disable trap-based bound checks,
this new API would allow it to adapt automatically while keeping the
optimization in the happy path, since it's not always possible for
end users to opt-into disabling trap-based bound checks (for example,
when a VS Code Server is loaded in a remote server for debugging).
Refs: nodejs#62132
Refs: microsoft/vscode#251777
Change-Id: I345c076af2b2b47700e5716b49c3133fdf8a0981
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7638233
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#105702}
Refs: v8/v8@bef0d9c
Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com>
PR-URL: nodejs#62132
Refs: microsoft/vscode#251777
Refs: https://chromium-review.googlesource.com/c/v8/v8/+/7638233
Reviewed-By: Aditi Singh <aditisingh1400@gmail.com>
Original commit message:
[runtime] always sort transition arrays during rehashing
After rehashing, the arrays are no longer in hash-sorted order.
In this case, we need to force a re-sort even for small arrays,
so that subsequent linear searches can find the correct transition
and avoid inserting duplicates.
Refs: nodejs#61898 (comment)
Change-Id: Ia813d1fb9d23e08012811d672052d235c0e0bf4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7723678
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#106255}
Refs: v8/v8@00f6e83
|
Thanks @legendecas and @StefanStojanovic, I added both patches. |
|
We're still blocked by AIX (GCC 12). @nodejs/platform-aix what's the status on the migration to Clang? |
Original commit message:
[runtime] Fix contextual stores to global with interceptor
According to the spec, contextual store in strict mode must first
check whether property exists and if not, the ReferenceError
should be thrown instead of calling the interceptor setter. See
https://tc39.es/ecma262/#sec-object-environment-records-setmutablebinding-n-v-s
Drive-by:
- introduce new Api v8::Object::GetPropertyAttributes(..) which is
able to return "property does not exist" result, which wasn't
possible with the existing GetPropertyAttributes(..) Api,
- update GenericInterceptor* callbacks in test-api-interceptors.cc
to better suite for implementing a proxy-like interceptor.
Bug: 455600234
Change-Id: I0986c18c406844f58c453e7aa7513c52a9097e04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7718821
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#106322}
Refs: v8/v8@088b711
Co-authored-by: Michaël Zasso <targos@protonmail.com>
This enables v8_enable_seeded_array_index_hash and add a test for it. Fixes: https://hackerone.com/reports/3511792 deps: V8: backport 0a8b1cdcc8b2 Original commit message: implement rapidhash secret generation Bug: 409717082 Change-Id: I471f33d66de32002f744aeba534c1d34f71e27d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6733490 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: snek <snek@chromium.org> Cr-Commit-Position: refs/heads/main@{#101499} Refs: v8/v8@0a8b1cd Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com> deps: V8: backport 185f0fe09b72 Original commit message: [numbers] Refactor HashSeed as a lightweight view over ByteArray Instead of copying the seed and secrets into a struct with value fields, HashSeed now stores a pointer pointing either into the read-only ByteArray, or the static default seed for off-heap HashSeed::Default() calls. The underlying storage is always 8-byte aligned so we can cast it directly into a struct. Change-Id: I5896a7f2ae24296eb4c80b757a5d90ac70a34866 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7609720 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#105531} Refs: v8/v8@185f0fe Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com> deps: V8: backport 1361b2a49d02 Original commit message: [strings] improve array index hash distribution Previously, the hashes stored in a Name's raw_hash_field for decimal numeric strings (potential array indices) consist of the literal integer value along with the length of the string. This means consecutive numeric strings can have consecutive hash values, which can lead to O(n^2) probing for insertion in the worst case when e.g. a non-numeric string happen to land in the these buckets. This patch adds a build-time flag v8_enable_seeded_array_index_hash that scrambles the 24-bit array-index value stored in a Name's raw_hash_field to improve the distribution. x ^= x >> kShift; x = (x * m1) & kMask; // round 1 x ^= x >> kShift; x = (x * m2) & kMask; // round 2 x ^= x >> kShift; // finalize To decode, apply the same steps with the modular inverses of m1 and m2 in reverse order. x ^= x >> kShift; x = (x * m2_inv) & kMask; // round 1 x ^= x >> kShift; x = (x * m1_inv) & kMask; // round 2 x ^= x >> kShift; // finalize where kShift = kArrayIndexValueBits / 2, kMask = kArrayIndexValueMask, m1, m2 (both odd) are the lower bits of the rapidhash secrets, m1_inv, m2_inv (modular inverses) are precomputed modular inverse of m1 and m2. The pre-computed values are appended to the hash_seed ByteArray in ReadOnlyRoots and accessed in generated code to reduce overhead. In call sites that don't already have access to the seeds, we read them from the current isolate group/isolate's read only roots. To consolidate the code that encode/decode these hashes, this patch adds MakeArrayIndexHash/DecodeArrayIndexFromHashField in C++ and CSA that perform seeding/unseeding if enabled, and updates places where encoding/decoding of array index is needed to use them. Bug: 477515021 Change-Id: I350afe511951a54c4378396538152cc56565fd55 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7564330 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#105596} Refs: v8/v8@1361b2a Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com> deps: V8: cherry-pick aac14dd95e5b Original commit message: [string] add 3rd round to seeded array index hash Since we already have 3 derived secrets, and arithmetics are relatively cheap, add a 3rd round to the xorshift-multiply seeding scheme. This brings the bias from ~3.4 to ~0.4. Bug: 477515021 Change-Id: I1ef48954bcee8768d8c90db06ac8adb02f06cebf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7655117 Reviewed-by: Chengzhong Wu <cwu631@bloomberg.net> Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#105824} Refs: v8/v8@aac14dd PR-URL: nodejs-private/node-private#834 CVE-ID: CVE-2026-21717 deps: V8: backport 185f0fe09b72 Original commit message: [numbers] Refactor HashSeed as a lightweight view over ByteArray Instead of copying the seed and secrets into a struct with value fields, HashSeed now stores a pointer pointing either into the read-only ByteArray, or the static default seed for off-heap HashSeed::Default() calls. The underlying storage is always 8-byte aligned so we can cast it directly into a struct. Change-Id: I5896a7f2ae24296eb4c80b757a5d90ac70a34866 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7609720 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#105531} Refs: v8/v8@185f0fe Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com> deps: V8: backport 1361b2a49d02 Original commit message: [strings] improve array index hash distribution Previously, the hashes stored in a Name's raw_hash_field for decimal numeric strings (potential array indices) consist of the literal integer value along with the length of the string. This means consecutive numeric strings can have consecutive hash values, which can lead to O(n^2) probing for insertion in the worst case when e.g. a non-numeric string happen to land in the these buckets. This patch adds a build-time flag v8_enable_seeded_array_index_hash that scrambles the 24-bit array-index value stored in a Name's raw_hash_field to improve the distribution. x ^= x >> kShift; x = (x * m1) & kMask; // round 1 x ^= x >> kShift; x = (x * m2) & kMask; // round 2 x ^= x >> kShift; // finalize To decode, apply the same steps with the modular inverses of m1 and m2 in reverse order. x ^= x >> kShift; x = (x * m2_inv) & kMask; // round 1 x ^= x >> kShift; x = (x * m1_inv) & kMask; // round 2 x ^= x >> kShift; // finalize where kShift = kArrayIndexValueBits / 2, kMask = kArrayIndexValueMask, m1, m2 (both odd) are the lower bits of the rapidhash secrets, m1_inv, m2_inv (modular inverses) are precomputed modular inverse of m1 and m2. The pre-computed values are appended to the hash_seed ByteArray in ReadOnlyRoots and accessed in generated code to reduce overhead. In call sites that don't already have access to the seeds, we read them from the current isolate group/isolate's read only roots. To consolidate the code that encode/decode these hashes, this patch adds MakeArrayIndexHash/DecodeArrayIndexFromHashField in C++ and CSA that perform seeding/unseeding if enabled, and updates places where encoding/decoding of array index is needed to use them. Bug: 477515021 Change-Id: I350afe511951a54c4378396538152cc56565fd55 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7564330 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#105596} Refs: v8/v8@1361b2a Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com> deps: V8: cherry-pick aac14dd95e5b Original commit message: [string] add 3rd round to seeded array index hash Since we already have 3 derived secrets, and arithmetics are relatively cheap, add a 3rd round to the xorshift-multiply seeding scheme. This brings the bias from ~3.4 to ~0.4. Bug: 477515021 Change-Id: I1ef48954bcee8768d8c90db06ac8adb02f06cebf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7655117 Reviewed-by: Chengzhong Wu <cwu631@bloomberg.net> Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#105824} Refs: v8/v8@aac14dd
Co-Authored-By: StefanStojanovic <stefan.stojanovic@janeasystems.com>
Add args to `tools/make-v8.sh` for compiling Rust-based components, such as Temporal, for the Linux on ppc64le and s390x V8 CI builds.
Use the method without context parameter; the old API is deprecated. Refs: https://crrev.com/c/7141498
Use the new API which gets a `ModuleCachingCallback` parameter. Refs: https://crrev.com/c/7078551
clang is installed on the three AIX test machines, but isn't currently selected by the |
|
Like Richard mentioned I've opened #62656 to add required changes to get aix building with clang. I do believe this update to 14.6 includes this v8 cherry-pick commit: 24119b8 so we can drop that ones the PR lands. The game plan I have in mind to get AIX building with clang:
|
Temporary commit. Just to test builds. Refs: #61898
PR for previous version: #61681