Original commit message:
Fix gcc build
For json-parser.h:
```
../../src/json/json-parser.h:298:13: error: explicit specialization in
non-namespace scope 'class v8::internal::JsonParser<Char>'
298 | template <>
| ^
../../src/json/json-parser.h:299:18: error: template-id
'IsNextToken<v8::internal::JsonToken::EOS>' in declaration of primary template
299 | V8_INLINE bool IsNextToken<JsonToken::EOS>() {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
```
For wasm-objects.cc:
```
../../src/wasm/wasm-objects.cc:2522:45: error: no matching function for call to
'v8::internal::WasmDispatchTable::SetForNonWrapper<v8::internal::WasmDispatchTable>(
v8::internal::WasmDispatchTable&, int&, v8::internal::Tagged<v8::internal::
Union<v8::internal::Smi, v8::internal::WasmTrustedInstanceData> >&,
v8::internal::WasmCodePointer&, v8::internal::wasm::CanonicalTypeIndex&,
v8::internal::WasmDispatchTable::NewOrExistingEntry&)'
```
```
error: no matching function for call to 'v8::internal::WasmDispatchTable::
SetForWrapper<v8::internal::WasmDispatchTable>(v8::internal::WasmDispatchTable&,
int&, v8::internal::Tagged<v8::internal::WasmImportData>&, std::shared_ptr<v8::
internal::wasm::WasmImportWrapperHandle>&, v8::internal::wasm::
CanonicalTypeIndex&, v8::internal::WasmDispatchTable::NewOrExistingEntry&)'
```
For the fix fully qualify calls to SetForWrapper and SetForNonWrapper with
::v8::internal:: to avoid accidental lookup of class member names.
This resolves template resolution errors caused by unqualified
calls inside WasmDispatchTable and WasmDispatchTableForImports
member functions.
Change-Id: I687935a05dc754db686deaa0f93079d350aae07e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7107891
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@ibm.com>
Cr-Commit-Position: refs/heads/main@{#103547}
Refs: 151d0a44a1
Co-authored-by: Michaël Zasso <targos@protonmail.com>
PR-URL: https://github.com/nodejs/node/pull/60488
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Richard Lau <richard.lau@ibm.com>
Original commit message:
[wasm] Fix DCHECK in AtomicWait after memory growth
With the changes in crrev.com/c/7003085, calling memory.grow()
via the JS API didn't immediately update the memory's array buffer
any more, which triggered a DCHECK in the runtime functions for
atomic waits. This patch restores immediate updating of the buffer
for the current isolate, which maintains the other CL's goal to
not allocate on loop back edges.
Fixed: 454991459
Change-Id: Id633cebb9ac24606bc0d8a3df703c74531d3c8a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7100806
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#103431}
Refs: 47800791b3
PR-URL: https://github.com/nodejs/node/pull/60488
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Richard Lau <richard.lau@ibm.com>
The original benchmark uses a not very realistic fixture (it has
a huge try-catch block that would throw on the first line and then
export at the end, hardly representative of real-world code).
Also, it measures the entire import including evaluation, not just
parsing. This updates the name to import-cjs to be more accurate,
and use the typescript.js as the fixture which has been reported
to be slow to import, leading users to use require() to work around
the peformance impact. It splits the measurement into two different
types: parsing CJS for the first time (where the overhead of
loading the lexer makes a difference) and parsing CJS after the
lexer has been loaded.
PR-URL: https://github.com/nodejs/node/pull/60663
Refs: https://github.com/nodejs/node/issues/59913
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
For riscv64, the most commonly supported paging mode is sv39, which
allocates 256GiB of virtual address space for the user space. However,
due to trap handler security mechanism in V8, creating a wasm memory
will cost 8GiB of continuous virtual address space. In a fresh node
repl, I could only create 27 WebAssembly.Memory instances. When the
virtual address space is more fragmented, it is worse.
The wpt tests are randomly failing on riscv64 due to insufficient
virtual address space to create wasm memories. This PR fixes it by
limiting the concurrency of the WPTRunner to prevent the tests from
creating too many wasm memories.
PR-URL: https://github.com/nodejs/node/pull/60591
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Recent architectures like RISC-V does not support open syscall,
which will cause strace to fail and thus test failure.
AssertionError [ERR_ASSERTION]: strace: invalid system call 'open'
This patch disables tracing open syscall for RISC-V in the test to fix
the test failure.
PR-URL: https://github.com/nodejs/node/pull/60588
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Richard Lau <richard.lau@ibm.com>
This test contains too many independent test cases and as a
result, marking it as flaky on all major platforms means
actual regressions could be covered up, and it's constantly
making the CI orange and requires extra resuming on the
flaked platforms which is still not great. Split it into
individual files so that the actual flake can be identified
out of the monolith.
PR-URL: https://github.com/nodejs/node/pull/60653
Refs: https://github.com/nodejs/node/issues/54534
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Instead of polyfilling it with vm.SourceTextModule,
use a built-in source text module loader so that we can
also build the code cache for it at build tiem to
embed the code cache for them in the binary.
Drive-by: instead of inferring how to compile a particular
built-in at run time, do the inferring at build time,
so the function-based built-ins can be compiled using
parameters quickly looked up from a static map, and
the builtins that should be compiled as source text
modules are known internally based on extension in
the source code (at run time, the extensions are all
removed).
PR-URL: https://github.com/nodejs/node/pull/60518
Reviewed-By: Aditi Singh <aditisingh1400@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
The previous busy loop wasn't robust enough in making sure
that the function runs for more than 1 nanosecond - and when it
runs faster than that on a fast machine, it measures to 0 for
nanosecond precision and throws a RangeErorr as histogram.record()
only takes positive values. Update it to use Atomics.wait() to
make sure that the function being measured runs for at least
1 millisecond so that the histogram always records a positive value.
PR-URL: https://github.com/nodejs/node/pull/60639
Fixes: https://github.com/nodejs/node/issues/60638
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
