Skip to content

deps: update V8 to 13.6 (bis) #58070

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 36 commits into
base: main
Choose a base branch
from
Open

deps: update V8 to 13.6 (bis) #58070

wants to merge 36 commits into from

Conversation

targos
Copy link
Member

@targos targos commented Apr 29, 2025

Same as #57753, without compatibility patches for MSVC and armv7.

Notable changes:

targos and others added 7 commits April 29, 2025 08:03
Major V8 updates are usually API/ABI incompatible with previous
versions. This commit adapts NODE_MODULE_VERSION for V8 13.6.

Refs: https://github.com/nodejs/CTC/blob/master/meetings/2016-09-28.md
PR-URL: nodejs#54077
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
PR-URL: nodejs#53134
Refs: nodejs#52809
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: nodejs#55014
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
It's causing linker errors with node.lib in node-gyp and potentially
breaks other 3rd party tools

PR-URL: nodejs#56238
Refs: nodejs#55784
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
PR-URL: nodejs#55014
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
GCC emits warnings because of the trailing backslashes.
@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/actions
  • @nodejs/gyp
  • @nodejs/performance
  • @nodejs/security-wg
  • @nodejs/tsc
  • @nodejs/v8-update
@nodejs-github-bot nodejs-github-bot added build Issues and PRs related to build files or the CI. dependencies Pull requests that update a dependency file. meta Issues and PRs related to the general management of the project. needs-ci PRs that need a full CI run. v8 engine Issues and PRs related to the V8 dependency. labels Apr 29, 2025
danmcd and others added 17 commits April 29, 2025 08:37
illumos pointers are VA48, can allocate from the top of the 64-bit range as well.
Original commit message:

    [api] add Isolate::Deinitialize() and Isolate::Free()

    This allows embedders to mirror the isolate disposal routine
    with an initialization routine that uses Isolate::Allocate().

    ```
    v8::Isolate* isolate = v8::Isolate::Allocate();
    // Use the isolate address as a key.
    v8::Isolate::Initialize(isolate, params);

    isolate->Deinitialize();
    // Remove the entry keyed by isolate address.
    v8::Isolate::Free(isolate);
    ```

    Previously, the only way to dispose the isolate bundles the
    de-initialization and the freeing of the address together in
    v8::Isolate::Dispose(). This is inadequate for embedders like
    Node.js that uses the isolate address as a key to manage the
    task runner associated with it, if another thread gets an
    isolate allocated at the aligned address before the other
    thread finishes cleanup for the isolate previously allocated
    at the same address, and locking on the entire disposal can
    be too risky since it may post GC tasks that in turn requires
    using the isolate address to locate the task runner. It's a
    lot simpler to handle the issue if the disposal process of
    the isolate can mirror the initialization of it and split
    into two routines.

    Refs: nodejs#57753 (comment)
    Refs: nodejs#30850
    Bug: 412943769
    Change-Id: I3865c27395aded3a6f32de74d96d0698b2d891b9
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6480071
    Reviewed-by: Leszek Swirski <leszeks@chromium.org>
    Commit-Queue: Joyee Cheung <joyee@igalia.com>
    Cr-Commit-Position: refs/heads/main@{#99890}

Refs: v8/v8@954187b
Build Node.js with simdutf version from V8.

Refs: v8/v8@d629051
Refs: v8/v8@616c875
Refs: v8/v8@e3204d5
Refs: v8/v8@e8293d2
Refs: v8/v8@aeb2220
Refs: v8/v8@5621164
Co-authored-by: Abdirahim Musse <abdirahim.musse@ibm.com>
The API was removed from V8.
New V8 version includes more information about regular expressions.
We depend on V8's version of simdutf now.
The location of some third-party code has changed.
targos and others added 12 commits April 29, 2025 08:38
`Isolate::AdjustAmountOfExternalAllocatedMemory` is deprecated.

Refs: v8/v8@7dc4c18
The `--expose_externalize_string` flag adds a new global.
As V8 is moving towards built-in CppHeap creation, change the
management so that the automatic CppHeap creation on Node.js's end
is also enforced at Isolate creation time.

1. If embedder uses NewIsolate(), either they use
  IsolateSettings::cpp_heap to specify a CppHeap that will be owned
  by V8, or if it's not configured, Node.js will create a CppHeap
  that will be owned by V8.
2. If the embedder uses SetIsolateUpForNode(),
  IsolateSettings::cpp_heap will be ignored (as V8 has deprecated
  attaching CppHeap post-isolate-creation). The embedders need to
  ensure that the v8::Isolate has a CppHeap attached while it's
  still used by Node.js, preferably using v8::CreateParams.

See https://issues.chromium.org/issues/42203693 for details. In
future version of V8, this CppHeap will be created by V8 if not
provided, and we can remove our own "if no CppHeap provided,
create one" code in NewIsolate().
The order of these calls is important. When the Isolate is disposed,
it may still post tasks to the platform, so it must still be registered
for the task runner to be found from the map. After the isolate is torn
down, we need to remove it from the map before we can free the address,
so that when another Isolate::Allocate() is called, that would not be
allocated to the same address and be registered on an existing map
entry.
@aduh95 aduh95 added the semver-major PRs that contain breaking changes and should be released in the next major version. label Apr 29, 2025
@targos
Copy link
Member Author

targos commented Apr 29, 2025

We still have this consistent macOS test failure on GitHub actions:

 Path: sequential/test-error-serdes
Error: --- stderr ---
node:internal/streams/readable:90
const FastBuffer = Buffer[SymbolSpecies];
                         ^

RangeError: Maximum call stack size exceeded
    at node:internal/streams/readable:90:26
    at BuiltinModule.compileForInternalLoader (node:internal/bootstrap/realm:398:7)
    at requireBuiltin (node:internal/bootstrap/realm:429:14)
    at node:internal/streams/duplex:39:18
    at BuiltinModule.compileForInternalLoader (node:internal/bootstrap/realm:398:7)
    at requireBuiltin (node:internal/bootstrap/realm:429:14)
    at node:internal/streams/pipeline:16:16
    at BuiltinModule.compileForInternalLoader (node:internal/bootstrap/realm:398:7)
    at requireBuiltin (node:internal/bootstrap/realm:429:14)
    at node:internal/streams/compose:7:22

Node.js v24.0.0-pre
Command: out/Release/node --expose-internals --stack-size=64 --test-reporter=./test/common/test-error-reporter.js --test-reporter-destination=stdout /Users/runner/work/node/node/node/test/sequential/test-error-serdes.js
Copy link

codecov bot commented Apr 29, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.64%. Comparing base (6cd1c09) to head (10bf2eb).
Report is 14 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #58070      +/-   ##
==========================================
- Coverage   90.21%   89.64%   -0.57%     
==========================================
  Files         630      630              
  Lines      186391   186416      +25     
  Branches    36610    36290     -320     
==========================================
- Hits       168146   167106    -1040     
- Misses      11066    12086    +1020     
- Partials     7179     7224      +45     

see 116 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
@legendecas
Copy link
Member

@targos I think we can safely increase the --stack-size flag in the test from 64 to some value like 128 or 256 to quickly remediate the failure. However, I did not find it is necessary to rely on the stack size in this test at all: #58075.

@targos
Copy link
Member Author

targos commented Apr 29, 2025

Now there are failing pummel/test-heapdump-... tests 😞

https://ci.nodejs.org/job/node-test-commit-linux-containered/50344/

@targos
Copy link
Member Author

targos commented Apr 29, 2025

And timeouts too while building addons on Windows

@targos
Copy link
Member Author

targos commented Apr 29, 2025

It's probably me being too optimistic when I removed #47450 (df034a3). I'll add it back when I rebase to fix the node_buffer.cc conflict.

@joyeecheung
Copy link
Member

joyeecheung commented Apr 30, 2025

If it's caused by enabling concurrent sparkplug it's likely #54918 (which might be fixed by #58047 but I will need more time to reason it out). For unblocking 24 it's better to keep it disabled for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Issues and PRs related to build files or the CI. dependencies Pull requests that update a dependency file. meta Issues and PRs related to the general management of the project. needs-ci PRs that need a full CI run. semver-major PRs that contain breaking changes and should be released in the next major version. v8 engine Issues and PRs related to the V8 dependency.
9 participants