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.
PR-URL: https://github.com/nodejs/node/pull/58070
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
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().
PR-URL: https://github.com/nodejs/node/pull/58070
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
If a worker has not already joined before running to completion
it will join in a SetImmediateThreadsafe which could occur after
the worker has already ended by other means. Mutating a JS object
at that point would fail because the isolate is already disposed.
PR-URL: https://github.com/nodejs/node/pull/56191
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Internal workers are essential to load user scripts and bootstrapped
with internal entrypoints. They should not be waiting for inspectors
even when `--inspect-brk` and `--inspect-wait` were specified, and avoid
blocking main thread to bootstrap.
IsolateData can be created with a specified PerIsolateOptions instead of
creating a copy from the per_process namespace. This also avoids
creating a copy bypassing the parent env's modified options, like
creating a worker thread from a worker thread.
PR-URL: https://github.com/nodejs/node/pull/54219
Fixes: https://github.com/nodejs/node/issues/53681
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
When the worker spawning code copies NODE_OPTIONS from process.env,
previously we do a check again on the copied NODE_OPTIONS and throw
if it contains per-process settings. This can be problematic
if the end user starts the process with a NODE_OPTIONS and the
worker is spawned by a third-party that tries to extend process.env
with some overrides before passing them into the worker. This patch
adds another exception that allows the per-process options in the
NODE_OPTIONS passed to a worker if the NODE_OPTIONS is
character-by-character equal to the parent NODE_OPTIONS.
While some more intelligent filter can be useful too,
this works good enough for the inheritance case, when the worker
spawning code does not intend to modify NODE_OPTIONS.
PR-URL: https://github.com/nodejs/node/pull/53596
Refs: https://github.com/nodejs/node/issues/41103
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Xuguang Mei <meixuguang@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
This PR adds a |preload| arg to the node::LoadEnvironment to allow
embedders to set a preload function for the environment, which will run
after the environment is loaded and before the main script runs.
This is similiar to the --require CLI option, but runs a C++ function,
and can only be set by embedders.
The preload function can be used by embedders to inject scripts before
running the main script, for example:
1. In Electron it is used to initialize the ASAR virtual filesystem,
inject custom process properties, etc.
2. In VS Code it can be used to reset the module search paths for
extensions.
PR-URL: https://github.com/nodejs/node/pull/51539
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
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>
This patch makes the binding templates ObjectTemplates, since we
don't actually need the constructor function. This also avoids
setting the properties on prototype, and instead initializes them
directly on the object template.
Previously the initialization was similar to:
```
function Binding() {}
Binding.prototype.property = ...;
module.exports = new Binding;
```
Now it's similar to:
```
module.exports = { property: ... };
```
PR-URL: https://github.com/nodejs/node/pull/47913
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Previously we modify the CLI options store to indicate whether the
isolate is created for building snapshot, which is a bit hacky and
makes it difficult to tell whether the snapshot is built from the
command line or through other APIs. This patch adds
is_building_snapshot to IsolateData and use this instead when we
need to know whether the isolate is created for building snapshot
(but do not care about where that request is coming from).
PR-URL: https://github.com/nodejs/node/pull/47887
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Add experimental support for loading snapshots in the embedder API
by adding a public opaque wrapper for our `SnapshotData` struct and
allowing embedders to pass it to the relevant setup functions.
Where applicable, use these helpers to deduplicate existing code
in Node.js’s startup path.
This has shown a 40 % startup performance increase for a real-world
application, even with the somewhat limited current support for
built-in modules.
The documentation includes a note about no guarantees for API or
ABI stability for this feature while it is experimental.
PR-URL: https://github.com/nodejs/node/pull/45888
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
daae938f32 broke addons which create their own `Isolate`
instances, because enabling the shared-readonly-heap feature
of V8 requires all snapshots used for different `Isolate`s to
be identical. Usage of addons that do this has probably
decreased quite a bit since Worker threads were introduced
in Node.js, but it’s still a valid use case, and in any case
the breakage was probably not intentional (although the referenced
commit did require test changes because of this issue).
This commit addresses this issue partially by caching the
V8 snapshot parameters and ignoring ones passed in from users
in `NewIsolate()` when this feature is enabled, and makes
the `NodeMainInstance` snapshot-based isolate creation
also re-use this code.
PR-URL: https://github.com/nodejs/node/pull/45885
Reviewed-By: James M Snell <jasnell@gmail.com>
The term `Environment` in `kAllowedInEnvironment` and
`kDisallowedInEnvironment` has nothing to do with the commonly used
term `node::Environment`. Rename the member to `kAllowedInEnvvar`
and `kDisallowedInEnvvar` respectively to reflect they are options
of `OptionEnvvarSettings`.
As `OptionEnvvarSettings` is part of the public embedder APIs, the
legacy names are still preserved.
PR-URL: https://github.com/nodejs/node/pull/45057
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Add an ExitCode enum class and use it throughout the code base
instead of hard-coding the exit codes everywhere. At the moment,
the exit codes used in many places do not actually conform to
what the documentation describes. With the new enums (which
are also available to the JS land as constants in an internal
binding) we could migrate to a more consistent usage of the
codes, and eventually expose the constants to the user land
when they are stable enough.
PR-URL: https://github.com/nodejs/node/pull/44746
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Jacob Smith <jacob@frende.me>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Instead of removing the callback before generating heap snapshot
and then adding it back after the heap snapshot is generated,
just remove it once the heap snapshot limit is reached.
Otherwise if the worker callback kicks in and sets the heap
limit to higher value during the heap snapshot generation,
the current_heap_limit in the heap snapshot callback becomes
invalid, and we might return a heap limit lower than the current
one, resulting in OOM.
In addition add more logs and checks in Worker::NearHeapLimit()
to help us catch problems.
PR-URL: https://github.com/nodejs/node/pull/44581
Refs: https://github.com/nodejs/reliability/issues/372
Reviewed-By: theanarkh <theratliter@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Worker.parent_port_ can be released before the exit event of Worker. The
parent_port_ is not owned by `node::worker::Worker`, thus the reference
to it is not always valid, and accessing it at exit crashes the process.
As the Worker.parent_port_ is only used in the memory info tracking, it
can be safely removed.
PR-URL: https://github.com/nodejs/node/pull/43123
Fixes: https://github.com/nodejs/node/issues/43122
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
theanarkh