This commit adds support for specifying --max-old-space-size as a
percentage of system memory, in addition to the existing MB format.
A new HandleMaxOldSpaceSizePercentage method parses percentage values,
validates that they are within the 0-100% range, and provides clear
error messages for invalid input. The heap size is now calculated
based on available system memory when a percentage is used.
Test coverage has been added for both valid and invalid cases.
Documentation and the JSON schema for CLI options have been updated
with examples for both formats.
Refs: https://github.com/nodejs/node/issues/57447
PR-URL: https://github.com/nodejs/node/pull/59082
Backport-PR-URL: https://github.com/nodejs/node/pull/59631
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: theanarkh <theratliter@gmail.com>
Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com>
This patch makes the off-thread loading lazy and only done when the
`tls` builtin is actually loaded by the application. Thus if the
application never uses tls, it would not get hit by the extra
off-thread loading overhead. paving the way to enable --use-system-ca
by default.
PR-URL: https://github.com/nodejs/node/pull/59856
Reviewed-By: James M Snell <jasnell@gmail.com>
This implements the execArgvExtension configuration field for SEA,
which takes one of three string values to specify whether and how
execution arguments can be extended for the SEA at run time:
* `"none"`: No extension is allowed. Only the arguments specified
in `execArgv` will be used,
and the `NODE_OPTIONS` environment variable will be ignored.
* `"env"`: _(Default)_ The `NODE_OPTIONS` environment variable can
extend the execution arguments.
This is the default behavior to maintain backward compatibility.
* `"cli"`: The executable can be launched with
`--node-options="--flag1 --flag2"`, and those flags
will be parsed as execution arguments for Node.js instead of being
passed to the user script. This allows using arguments that are
not supported by the `NODE_OPTIONS` environment variable.
PR-URL: https://github.com/nodejs/node/pull/59560
Fixes: https://github.com/nodejs/node/issues/55573
Fixes: https://github.com/nodejs/single-executable/issues/100
Refs: https://github.com/nodejs/node/issues/51688
Reviewed-By: Xuguang Mei <meixuguang@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
If `--enable-fips` or `--force-fips` fails to be applied during
`ProcessFipsOptions()`, the node process might exit with
`ExitCode::kNoFailure` because `ERR_GET_REASON(ERR_peek_error())` can
return `0` since `ncrypto::testFipsEnabled()` does not populate the
OpenSSL error queue.
You can likely test this locally by running
node --enable-fips && echo $?
with the current `node` binary from the main branch if compiled without
support for FIPS.
As confirmed by the `XXX` comment here, which was added three years ago
in commit b697160256, even if the error
queue was populated properly, the OpenSSL reason codes are not really
related to the Node.js `ExitCode` enumeration.
PR-URL: https://github.com/nodejs/node/pull/58379
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Node calls tcsetattr on exit to reset the tty to its state on program
start. Good idea in general but tcsetattr can fail for a number of
reasons and since there really isn't anything we can do about it
at that point, simply ignore the error instead of aborting with
an inscrutable error message.
Most of the time it'll be fine because the most common failure is when
the user has already logged off and there isn't anything to restore in
the first place.
Fixes: https://github.com/nodejs/node/issues/51519
PR-URL: https://github.com/nodejs/node/pull/58200
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
- We do not actually need them in PEM format, so just pass them
around as X509 direcrtly.
- The cached global X509 structures were previously never cleaned
up. Clean them up at process teardown.
- Use function-local static to ensure thread-safety in
initialization.
- Add more comments about how the various options differ.
PR-URL: https://github.com/nodejs/node/pull/56999
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
This implements --trace-env, --trace-env-js-stack and
--trace-env-native-stack CLI options which can be used to find
out what environment variables are accessed and where they are
accessed.
PR-URL: https://github.com/nodejs/node/pull/55604
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
This patch:
1. Refactor the routines used to compile and run an embedder
entrypoint. In JS land special handling for SEA is done
directly in main/embedding.js instead of clobbering the CJS
loader. Add warnings to remind users that currently the
require() in SEA bundled scripts only supports loading builtins.
2. Don't use the bundled SEA code cache when compiling CJS
loaded from disk, since in that case we are certainly not
compiling the code bundled into the SEA. Use a is_sea_main
flag in CompileFunctionForCJSLoader() (which replaces an unused
argument) to pass this into the C++ land - the code cache is
still read directly from C++ to avoid the overhead of
ArrayBuffer creation.
3. Move SEA loading code into
MaybeLoadSingleExecutableApplication() which calls
LoadEnvironment() with its own StartExecutionCallback().
This avoids more hidden switches in StartExecution() and
make them explicit. Also add some TODOs about how to support
ESM in embedded applications.
4. Add more comments
PR-URL: https://github.com/nodejs/node/pull/53573
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
By default, Node.js enables trap-handler-based WebAssembly bound
checks. As a result, V8 does not need to insert inline bound checks
int the code compiled from WebAssembly which may speedup WebAssembly
execution significantly, but this optimization requires allocating
a big virtual memory cage (currently 10GB). If the Node.js process
does not have access to a large enough virtual memory address space
due to system configurations or hardware limitations, users won't
be able to run any WebAssembly that involves allocation in this
virtual memory cage and will see an out-of-memory error.
```console
$ ulimit -v 5000000
$ node -p "new WebAssembly.Memory({ initial: 10, maximum: 100 });"
[eval]:1
new WebAssembly.Memory({ initial: 10, maximum: 100 });
^
RangeError: WebAssembly.Memory(): could not allocate memory
at [eval]:1:1
at runScriptInThisContext (node:internal/vm:209:10)
at node:internal/process/execution:118:14
at [eval]-wrapper:6:24
at runScript (node:internal/process/execution:101:62)
at evalScript (node:internal/process/execution:136:3)
at node:internal/main/eval_string:49:3
```
`--disable-wasm-trap-handler` disables this optimization so that
users can at least run WebAssembly (with a less optimial performance)
when the virtual memory address space available to their Node.js
process is lower than what the V8 WebAssembly memory cage needs.
PR-URL: https://github.com/nodejs/node/pull/52766
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
The V8 WebAssembly trap handler setup for Windows was incorrectly
nested within a POSIX conditional compilation block in src/node.cc.
This caused the related functions to be effectively non-operational
on Windows. The changes involve removing the Windows-specific code from
the POSIX section and correctly placing it under the WIN32 check.
This fix will ensure that the intended exception handling is active
on Windows builds.
Fixes: https://github.com/nodejs/node/issues/52404
Refs: https://github.com/nodejs/node/pull/35033
PR-URL: https://github.com/nodejs/node/pull/52545
Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
This patch removes support for the `assert` keyword
for import attributes. It was an old variant of the
proposal that was only shipped in V8 and no other
engine, and that has then been replaced by the `with`
keyword.
Chrome is planning to remove support for `assert`
in version 126, which will be released in June.
Node.js already supports the `with` keyword for
import attributes, and this patch does not change that.
PR-URL: https://github.com/nodejs/node/pull/52104
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
Previously it would not compile if the build is configured with
--disable-single-executable-application because we use directives
to exclude the definition of SEA-related code completely. This patch
changes them so that the SEA code are still compiled and internals
can still check whether the executable is an SEA. The executable would
not try to load the SEA blob at all if SEA is disabled. If future
modifications to the C++ code attempt to load the SEA blob when SEA
is disabled, UNREACHABLE() would be raised. If user attempt to
generate the SEA blob with --experimental-sea-config with an executable
that disables SEA, they would get an error.
PR-URL: https://github.com/nodejs/node/pull/51808
Fixes: https://github.com/nodejs/node/issues/51730
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
In many cases we can query the environment variable directly instead
of encoding it into UTF8 first and then decoding it again from
UTF8 via an intermediate V8 string.
Drive-by: pass per_process::system_environment explicitly when
the real environment variables are supposed to be used instead of
relying on fallback with defaults.
PR-URL: https://github.com/nodejs/node/pull/51829
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Previously we wrapped the embedder entry point callback into a
binding and then invoke the binding from JS land which was a bit
convoluted. Now we just call it directly from C++.
The main scripts that needed to tail call the embedder callback now
return the arguments in an array so that the C++ land can extract
the arguments and pass them to the callback. We also set
`PauseOnNextJavascriptStatement()` for --inspect-brk and mark
the bootstrap complete milestone directly in C++ for these
execution modes.
PR-URL: https://github.com/nodejs/node/pull/51557
Reviewed-By: Daniel Lemire <daniel@lemire.me>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
- Add support for --build-snapshot-config which allows passing
snapshot configurations via a JSON configuration file.
- Add support for node::SnapshotConfig in the embedder API
The initial configurable options are:
- "builder" (SnapshotConfig::builder_script_path): path to the
builder script.
- "withoutCodeCache" (SnapshotFlags::kWithoutCodeCache): disable
code cache generation.
PR-URL: https://github.com/nodejs/node/pull/50453
Refs: https://github.com/nodejs/node/issues/42566
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
This patch implements a debugging flag that dumps the current
stack trace when a promise is created or resolved. To reduce
noise we ignore before and after events (as the execution is
less interesting) and use the per-isolate hook to avoid extra
JS frames. This flag can assist work in reducing unnecessary
promise overhead.
PR-URL: https://github.com/nodejs/node/pull/50899
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
To improve determinism of snapshot generation, add --predictable
to the V8 flags used to initialize a process launched to generate
snapshot. Also add a kGeneratePredictableSnapshot flag
to ProcessInitializationFlags for this and moves the configuration
of these flags into node::InitializeOncePerProcess() so that
it can be shared by embedders.
PR-URL: https://github.com/nodejs/node/pull/48749
Refs: https://github.com/nodejs/build/issues/3043
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Previously when we fail to initialize ICU data, the error message is
```
could not initialize ICU (check NODE_ICU_DATA or --icu-data-dir
parameters)
```
This patch updates it to something similar to:
```
U_FILE_ACCESS_ERROR: Could not initialize ICU. Check the directory
specified by NODE_ICU_DATA or --icu-data-dir contains icudt73l.dat
and it's readable
```
Where the expected data file name is the same as U_ICUDATA_NAME.
PR-URL: https://github.com/nodejs/node/pull/49666
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
This patch adds snapshot support to single executable applications.
To build a snapshot from the main script when preparing the
blob that will be injected into the single executable application,
add `"useSnapshot": true` to the configuration passed to
`--experimental-sea-config`. For example:
```
{
"main": "snapshot.js",
"output": "sea-prep.blob",
"useSnapshot": true
}
```
The main script used to build the snapshot must invoke
`v8.startupSnapshot.setDeserializeMainFunction()` to configure the
entry point. The generated startup snapshot would be part of the
preparation blob and get injected into the final executable.
When the single executable application is launched, instead of running
the `main` script from scratch, Node.js would instead deserialize the
snapshot to get to the state initialized during build-time directly.
PR-URL: https://github.com/nodejs/node/pull/46824
Refs: https://github.com/nodejs/single-executable/discussions/57
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
- Run the embedder entry point directly through
runEmbedderEntryPoint(), instead of going through another
JS -> C++ trip through the function returned by
getEmbedderEntryFunction()
- For --build-snapshot, read the snapshot script code directly in C++
and pass it to SnapshotBuilder::Generate(), this makes the entry point
more explicit instead of hiding it in JS land, and also makes it
possible to invoke SnapshotBuilder::Generate() internally to create
a custom snapshot.
- Previously we used process.execPath for the embedder to create
__filename and __dirname in the snapshot builder script while using
process.argv[1] for --build-snapshot (where it's always set) which
results in inconsistencies. We now require the embedder to also set
args[1] when creating the Environment if they intend to run snapshot
scripts with a context that contains __filename and __dirname, which
would be derived from args[1]. If they prefer not to include
build-time paths in the snapshot, we now provide
node::GetAnonymousMainPath() as an alternative.
PR-URL: https://github.com/nodejs/node/pull/48242
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Joyee Cheung