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>
The sea tests are only run sequentially to avoid taking too much
disk space. When there is enough disk space, however, it's better
to run them in parallel, as these tests tend to be slow.
PR-URL: https://github.com/nodejs/node/pull/60604
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
When the source text module is compiled without custom callbacks,
instead of calling into JS land from the per-isolate import.meta
initializer and then back to C++ land to set up lazy data
properties, just do the initialization all in C++ land.
Only import.meta.resolve initialization will call back
into JS land to generate a closure that call the cascaded loader
for resolution.
In addition, simplify the loader structure by merging
allowImportMetaResolve into isForAsyncLoaderHookWorker - the two
are essentially equivalent, as import.meta.resolve is only
allowed in a non-loader-hook worker thread's loader.
PR-URL: https://github.com/nodejs/node/pull/60603
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
`events.once` is a great way to manage the `close` / `error` / `exit`
events of a child process. It creates a Promise that is fulfilled when
the EventEmitter emits the given event or that is rejected if the
EventEmitter emits 'error' while waiting.
I think a lot of people wrongly think that managing a spawned child
process requires writing boilerplate handlers for `close` and `error`,
and that there's no `promisify` solution for spawned child processes. In
fact, `events.once` is that solution. The docs should explicitly
recommend it in examples.
PR-URL: https://github.com/nodejs/node/pull/60017
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
`src/node_modules.cc` needs to be consistent with `src/node_file.cc` in
how it translates the utf8 strings to `std::wstring` otherwise we might
end up in situation where we can read the source code of imported
package from disk, but fail to recognize that it is an ESM (or CJS) and
cause runtime errors. This type of error is possible on Windows when the
path contains unicode characters and "Language for non-Unicode programs"
is set to "Chinese (Traditional, Taiwan)".
See: #58768
PR-URL: https://github.com/nodejs/node/pull/60575
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Stefan Stojanovic <stefan.stojanovic@janeasystems.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Previously when the child process helpers are used to print
information about the failed expectations and the env of the
child process was overridden, it printed the entire env object,
which may be too much if the caller does something like
{ env: { ENV: 'var', ...process.env } } (which tend to be always
the case for specifying env because we need to copy the
process.env for dynamic library loading in the CI).
This updates it to only show the env vars that differ from
process.env for a cleaner log in the case of failure.
PR-URL: https://github.com/nodejs/node/pull/60556
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
