nodejs
deps: update V8 to 13.0
Review requested:
- [ ] @nodejs/gyp
- [ ] @nodejs/security-wg
- [ ] @nodejs/v8-update
I get the notable changes from https://chromestatus.com/roadmap.
There's nothing about disposable there (and using still triggers a syntax error), why do you expect it to be available?
Probably. The tracking issue is still open: https://issues.chromium.org/issues/42203506
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=benchmark-ubuntu2204-intel-64,v8test=v8test/6203/
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=rhel8-s390x,v8test=v8test/6203/
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=rhel8-ppc64le,v8test=v8test/6203/
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 88.69%. Comparing base (
304bb9c) to head (63ee9f0). Report is 22 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #55014 +/- ##
==========================================
- Coverage 89.20% 88.69% -0.52%
==========================================
Files 663 663
Lines 192012 192012
Branches 36929 36615 -314
==========================================
- Hits 171286 170306 -980
- Misses 13582 14530 +948
- Partials 7144 7176 +32
![codecov[bot] avatar](https://avatars.githubusercontent.com/in/254?v=4 "Published by a pub.dev verified publisher"){kind=small}
@nodejs/platform-windows MSVC complains:
23:17:25 C:\workspace\node-compile-windows-debug\node\deps\v8\src\interpreter\interpreter-generator-tsa.cc(333,1): error C2872: 'Block': ambiguous symbol [C:\workspace\node-compile-windows-debug\node\tools\v8_gypfiles\v8_initializers.vcxproj]
23:17:25 C:\workspace\node-compile-windows-debug\node\deps\v8\src\ast\ast.h(318,7): message : could be 'v8::internal::Block' [C:\workspace\node-compile-windows-debug\node\tools\v8_gypfiles\v8_initializers.vcxproj]
23:17:25 C:\workspace\node-compile-windows-debug\node\deps\v8\src\compiler\turboshaft\graph.h(306,7): message : or 'v8::internal::compiler::turboshaft::Block' [C:\workspace\node-compile-windows-debug\node\tools\v8_gypfiles\v8_initializers.vcxproj]
23:17:25 C:\workspace\node-compile-windows-debug\node\deps\v8\src\interpreter\interpreter-generator-tsa.cc(333,1): error C2440: 'initializing': cannot convert from 'v8::internal::compiler::turboshaft::Block *' to 'v8::internal::Block *' [C:\workspace\node-compile-windows-debug\node\tools\v8_gypfiles\v8_initializers.vcxproj]
23:17:25 C:\workspace\node-compile-windows-debug\node\deps\v8\src\interpreter\interpreter-generator-tsa.cc(333,1): message : Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or parenthesized function-style cast [C:\workspace\node-compile-windows-debug\node\tools\v8_gypfiles\v8_initializers.vcxproj]
23:17:25 C:\workspace\node-compile-windows-debug\node\deps\v8\src\interpreter\interpreter-generator-tsa.cc(333,1): error C2665: 'v8::internal::compiler::turboshaft::CatchScopeImpl<v8::internal::compiler::turboshaft::Assembler<v8::internal::compiler::turboshaft::reducer_list<v8::internal::compiler::turboshaft::TurboshaftAssemblerOpInterface,Reducer,v8::internal::interpreter::BytecodeHandlerReducer,v8::internal::BuiltinsReducer,v8::internal::FeedbackCollectorReducer,v8::internal::compiler::turboshaft::MachineLoweringReducer,v8::internal::compiler::turboshaft::VariableReducer,v8::internal::compiler::turboshaft::TSReducerBase>>>::CatchScopeImpl': no overloaded function could convert all the argument types [C:\workspace\node-compile-windows-debug\node\tools\v8_gypfiles\v8_initializers.vcxproj]
@ronag @anonrig
It seems that something changed with the fast API which results in fast C++ functions not being called when they expect FastOneByteString arguments (I verified the tests with --trace-opt --trace-deopt. The JS functions are still optimized).
I don't know what to do here other than https://github.com/nodejs/node/pull/55014/commits/112b303a469111eb17ea812265e78209a6734f2d
So basically Fast API is "broken"? This will cause some massive perf regressions (maybe good idea to kick of a benchmark CI to confirm). Can we involve someone with V8 knowledge? If benchmarks do not show regressions then I agree that we just apply https://github.com/nodejs/node/commit/112b303a469111eb17ea812265e78209a6734f2d as a workaround.
Either fast API is "broken", or the strings used in the test are no longer of the kind "fast one-byte".
So basically Fast API is "broken"?
No, the test is. At least two of the four calls pass two-byte strings.
I believe v8/v8@a1ada7703d2274017ebef4886e9f7404912a63bd is the responsible change upstream.
I'm trying to upstream a fix for the MSVC error: https://chromium-review.googlesource.com/c/v8/v8/+/5878257
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=benchmark-ubuntu2204-intel-64,v8test=v8test/6214/
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=rhel8-s390x,v8test=v8test/6214/
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/nodes=rhel8-ppc64le,v8test=v8test/6214/
Updated https://github.com/nodejs/node/pull/55014/commits/e68b2f6b9c82a37fe70c445c09526abceb2a40f2 to fix the typename error.
This PR requires newer macOS versions in CI.
Is this the only blocker for this PR?
