Refactor the internal NativeModule class to a JS class and add
more documentation about its properties.
PR-URL: https://github.com/nodejs/node/pull/30856
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Rich Trott <rtrott@gmail.com>
CLI options should not be added through the config binding, instead
they are already available in the JS land via
`require('internal/options')`. Also CLI options in principle should
be processed in pre-execution instead of bootstrap scripts.
PR-URL: https://github.com/nodejs/node/pull/30778
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Store all primordials as properties of the primordials object.
Static functions are prefixed by the constructor's name and prototype
methods are prefixed by the constructor's name followed by "Prototype".
For example: primordials.Object.keys becomes primordials.ObjectKeys.
PR-URL: https://github.com/nodejs/node/pull/30610
Refs: https://github.com/nodejs/node/issues/29766
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Due to how bootstrap/loaders.js itself is loaded and invoked,
stacktraces from it are munged and no longer point back to the error
source.
That resulted in the following unhelpful error if an internal module
was missing or misnamed:
```
internal/bootstrap/loaders.js:190
return mod.compile();
^
TypeError: Cannot read property 'compile' of undefined
```
This changes that to at least print the id that was attempted to be
loaded:
```
internal/bootstrap/loaders.js:189
if (!mod) throw new TypeError(`Missing internal module '${id}'`);
^
TypeError: Missing internal module 'internal/a'
```
PR-URL: https://github.com/nodejs/node/pull/29593
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Since the bootstrap does not actually use ESM at all, there
is no need to create this map so early. This patch moves
the initialization of the map to pre-execution,
so that the only binding loaded in loaders is native_module.
In addition, switch to SafeWeakMap.
PR-URL: https://github.com/nodejs/node/pull/27323
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
This changes the primordials to expose built-in prototypes with their
methods already uncurried.
The uncurryThis function is therefore moved to the primordials.
All uses of uncurryThis on built-ins are changed to import the relevant
prototypes from primordials.
All uses of Function.call.bind are also changed to use primordials.
PR-URL: https://github.com/nodejs/node/pull/27096
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
This patch removes the redundant `require-globals` custom
eslint rule by removing `env: node` in the eslint config
and whitelist the globals that can be accessed in native
modules instead of black listing them. This makes sense
for our `lib/` files because here we are creating the
Node.js environment instead of running in a normal user
land Node.js environment.
PR-URL: https://github.com/nodejs/node/pull/27082
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Instead of relying on the value of the CLI option when
executing bootstrap/loaders.js.
PR-URL: https://github.com/nodejs/node/pull/26759
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
This patch removes `NativeModule.require` and
`NativeModule.requireWithFallbackInDeps`. The public loaders now
have to use a special method
`NativeModule.prototype.compileForPublicLoader()` to compile native
modules. In addition this patch moves the decisions of proxifying
exports and throwing unknown builtin errors entirely to public
loaders, and skip those during internal use - therefore `loaders.js`,
which is compiled during bootstrap, no longer needs to be aware of
the value of `--experimental-modules`.
PR-URL: https://github.com/nodejs/node/pull/26549
Reviewed-By: James M Snell <jasnell@gmail.com>
This patch moves the dispatch of `Profiler.takePreciseCoverage`
to a point before the bootstrap scripts are run to ensure that
we can collect coverage data for all the scripts run after
the inspector agent is ready.
Before this patch `lib/internal/bootstrap/primordials.js` was not
covered by `make coverage`, after this patch it is.
PR-URL: https://github.com/nodejs/node/pull/26006
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Coe <bencoe@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
There are no non-internal builtin modules left, so this
should be safe to remove to a large degree.
PR-URL: https://github.com/nodejs/node/pull/25829
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This patches changes the `safe_globals` internal module into a
script that gets run during bootstrap and saves JavaScript builtins
(primordials) into an object that is available for all other builtin
modules to access lexically later.
PR-URL: https://github.com/nodejs/node/pull/25816
Refs: https://github.com/nodejs/node/issues/18795
Reviewed-By: Bradley Farias <bradley.meck@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gus Caplan <me@gus.host>
This patch splits the execution mode selection from the environment
setup in `lib/internal/bootstrap/node.js`, and split the entry point
of different execution mode into main scripts under
`lib/internal/main`:
- `check_syntax.js`: used when `-c`/`--check` which only checks the
syntax of the input instead of executing it.
- `eval_stdin.js`: used when `-e` is passed without value and stdin
is not a TTY (e.g. something is piped).
- `eval_string`: used when `-e` is passed along with a string argument
- `inspect.js`: for `node inspect`/`node debug`
- `print_bash_completion.js`: for `--completion-bash`
- `print_help.js`: for `--help`
- `prof_process.js`: for `--prof-process`
- `repl.js`: for the REPL
- `run_main_module.js`: used when a main module is passed
- `run_third_party_main.js`: for the legacy `_third_party_main.js`
support
- `worker_thread.js`: for workers
This makes the entry points easier to navigate and paves the way
for customized v8 snapshots (that do not need to deserialize
execution mode setup) and better embedder APIs.
As an example, after this patch, for the most common case where
Node.js executes a user module as an entry point, it essentially
goes through:
- `lib/internal/per_context.js` to setup the v8 Context (which is
also run when setting up contexts for the `vm` module)
- `lib/internal/bootstrap/loaders.js` to set up internal binding
and builtin module loaders (that are separate from the loaders
accessible in the user land).
- `lib/internal/bootstrap/node.js`: to set up the rest of the
environment, including various globals and the process object
- `lib/internal/main/run_main_module.js`: which is selected from
C++ to prepare execution of the user module.
This patch also removes `NativeModuleLoader::CompileAndCall` and
exposes `NativeModuleLoader::LookupAndCompile` directly so that
we can handle syntax errors and runtime errors of bootstrap
scripts differently.
PR-URL: https://github.com/nodejs/node/pull/25667
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Instead of using `internalBinding('config')` which should be used
to carry information about build-time options, directly pass the
run-time cli options into bootstrap/loaders.js lexically via
function arguments.
PR-URL: https://github.com/nodejs/node/pull/25463
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Refael Ackermann <refack@gmail.com>
- Renamed `internal/process/write-coverage.js` to
`internal/coverage-gen/with_instrumentation.js`,
`internal/process/coverage.js` to
`internal/coverage-gen/with_profiler.js` to distinguish
the two better and added comments.
- Separate the coverage directory setup and the connection
setup, moves the directory setup into `node.js` and
closer to the exit hooks because that's where it's used.
- Moves the `process.reallyExit` overwrite and
`process.on('exit')` hooks setup into bootstrap/node.js
for clarity, and move them to a later stage of
bootstrap since they do not have to happen that early.
PR-URL: https://github.com/nodejs/node/pull/25398
Reviewed-By: Ben Coe <bencoe@gmail.com>
- Remove `NativeModule._source` - the compilation is now entirely
done in C++ and `process.binding('natives')` is implemented
directly in the binding loader so there is no need to store
additional source code strings.
- Instead of using an object as `NativeModule._cached` and insert
into it after compilation of each native module, simply prebuild
a JS map filled with all the native modules and infer the
state of compilation through `mod.loading`/`mod.loaded`.
- Rename `NativeModule.nonInternalExists` to
`NativeModule.canBeRequiredByUsers` and precompute that
property for all the native modules during bootstrap instead
of branching in every require call during runtime. This also fixes
the bug where `worker_threads` can be made available with
`--expose-internals`.
- Rename `NativeModule.requireForDeps` to
`NativeModule.requireWithFallbackInDeps`.
- Add a test to make sure we do not accidentally leak any module
to the global namespace.
PR-URL: https://github.com/nodejs/node/pull/25352
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Having an experimental feature behind a flag makes change
if we are expecting significant breaking changes to its API.
Since the Worker API has been essentially stable since
its initial introduction, and no noticeable doubt about
possibly not keeping the feature around has been voiced,
removing the flag and thereby reducing the barrier to experimentation,
and consequently receiving feedback on the implementation,
seems like a good idea.
PR-URL: https://github.com/nodejs/node/pull/25361
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Yuta Hiroto <hello@hiroppy.me>
Reviewed-By: Shingo Inoue <leko.noor@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Masashi Hirano <shisama07@gmail.com>
Reviewed-By: Weijia Wang <starkwang@126.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
This brings DEP0084 to End-of-Life. It is unlikely that this
has received much public usage in the first place, so removing
should be okay.
PR-URL: https://github.com/nodejs/node/pull/25138
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/25087
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
We now compile the native modules in C++ so these are no longer
used.
PR-URL: https://github.com/nodejs/node/pull/24904
Refs:https://github.com/joyeecheung/node/commit/bd765d61d7
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Instead of treating config.gypi as a JavaScript file, specialize
the processing in js2c and make the serialized result a real JSON
string (with 'true' and 'false' converted to boolean values) so
we don't have to use a custom deserializer during bootstrap.
In addition, store the JSON string separately in NativeModuleLoader,
and keep it separate from the map of the builtin source code, so
we don't have to put it onto `NativeModule._source` and delete it
later, though we still preserve it in `process.binding('natives')`,
which we don't use anymore.
This patch also makes the map of builtin source code and the
config.gypi string available through side-effect-free getters
in C++.
PR-URL: https://github.com/nodejs/node/pull/24816
Reviewed-By: Gus Caplan <me@gus.host>
This patch moves all the bootstrapper compilation to use
NativeModuleLoader::CompileAndCall(). With this we no longer
need to mess with the error decoration and handling any more -
there is no point in handling the JS error occurred during bootstrapping
by ourselves, we should just crash or let the VM handle it.
PR-URL: https://github.com/nodejs/node/pull/24775
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
This patch refactors out a part of NativeModule.prototype.compile
(in JS land) into a C++ NativeModule class, this enables a
couple of possibilities:
1. By moving the code to the C++ land, we have more opportunity
to specialize the compilation process of the native modules
(e.g. compilation options, code cache) that is orthogonal to
how user land modules are compiled
2. We can reuse the code to compile bootstrappers and context
fixers and enable them to be compiled with the code cache later,
since they are not loaded by NativeModule in the JS land their
caching must be done in C++.
3. Since there is no need to pass the static data to JS for
compilation anymore, this enables us to use
(std::map<std::string, const char*>) in the generated
node_code_cache.cc and node_javascript.cc later, and scope
every actual access to the source of native modules to a
std::map lookup instead of a lookup on a v8::Object in
dictionary mode.
This patch also refactor the code cache generator and tests
a bit and trace the `withCodeCache` and `withoutCodeCache`
in a Set instead of an Array, and makes sure that all the cachable
builtins are tested.
PR-URL: https://github.com/nodejs/node/pull/24221
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
PR-URL: https://github.com/nodejs/node/pull/24292
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Weijia Wang <starkwang@126.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Instead of calling into C++ each time we need to check the value
of a command line option, cache the option map in a new
`internal/options` module for faster access to the values in JS land.
PR-URL: https://github.com/nodejs/node/pull/24091
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Instead of setting the internalBinding white list in node.js and
wrapping process.binding twice, put it directly in loaders.js
where the user land process.binding is defined.
PR-URL: https://github.com/nodejs/node/pull/24088
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Also added the comment in f074612b7 to make
NativeModule.prototype.compile() more readable.
PR-URL: https://github.com/nodejs/node/pull/24057
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Refael Ackermann <refack@gmail.com>
internalBinding is used so often that it should just automatically be
available for usage in internals.
PR-URL: https://github.com/nodejs/node/pull/23025
Refs: https://github.com/nodejs/node/commit/2a9eb31
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Currently V8 only checks that the length of the source code is the
same as the code used to generate the hash, so we add an additional
check here:
1. During compile time, when generating node_javascript.cc and
node_code_cache.cc, we compute and include the hash of the
(unwrapped) JavaScript source in both.
2. At runtime, we check that the hash of the code being compiled
and the hash of the code used to generate the cache
(inside the wrapper) is the same.
This is based on the assumptions:
1. `internalBinding('code_cache_hash')` must be in sync with
`internalBinding('code_cache')` (same C++ file)
2. `internalBinding('natives_hash')` must be in sync with
`process.binding('natives')` (same C++ file)
3. If `internalBinding('natives_hash')` is in sync with
`internalBinding('natives_hash')`, then the (unwrapped)
code used to generate `internalBinding('code_cache')`
should be in sync with the (unwrapped) code in
`process.binding('natives')`
There will be, however, false positives if the wrapper used
to generate the cache is different from the one used at run time,
and the length of the wrapper somehow stays the same.
But that should be rare and can be eased once we make the
two bootstrappers cached and checked as well.
PR-URL: https://github.com/nodejs/node/pull/22152
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
This patch makes it possible to generate the code cache
for the builtins directly from the original script object
(instead of compiling a new one) and after the script has
been run (via `NativeModule.require`). Before this patch
only the top level functions (the wrapped ones)
are included in the cache, after this patch the inner
functions in those modules will be included as well.
Also blacklists modules from dependencies like V8 and
node-inspect since we cannot guarantee that they are suitable
to be executed directly.
PR-URL: https://github.com/nodejs/node/pull/21567
Refs: https://github.com/nodejs/node/issues/21563
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: John-David Dalton <john.david.dalton@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This patch speeds up the startup time and reduce the startup memory
footprint by using V8 code cache when comiling builtin modules.
The current approach is demonstrated in the `with-code-cache`
Makefile target (no corresponding Windows target at the moment).
1. Build the binary normally (`src/node_code_cache_stub.cc` is used),
by now `internalBinding('code_cache')` is an empty object
2. Run `tools/generate_code_cache.js` with the binary, which generates
the code caches by reading source code of builtin modules off source
code exposed by `require('internal/bootstrap/cache').builtinSource`
and then generate a C++ file containing static char arrays of the
code cache, using a format similar to `node_javascript.cc`
3. Run `configure` with the `--code-cache-path` option so that
the newly generated C++ file will be used when compiling the
new binary. The generated C++ file will put the cache into
the `internalBinding('code_cache')` object with the module
ids as keys
4. The new binary tries to read the code cache from
`internalBinding('code_cache')` and use it to compile
builtin modules. If the cache is used, it will put the id
into `require('internal/bootstrap/cache').compiledWithCache`
for bookkeeping, otherwise the id will be pushed into
`require('internal/bootstrap/cache').compiledWithoutCache`
This patch also added tests that verify the code cache is
generated and used when compiling builtin modules.
The binary with code cache:
- Is ~1MB bigger than the binary without code cahe
- Consumes ~1MB less memory during start up
- Starts up about 60% faster
PR-URL: https://github.com/nodejs/node/pull/21405
Reviewed-By: John-David Dalton <john.david.dalton@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gus Caplan <me@gus.host>
This commit is a suggestion to add a new option to the node executable
to allow for breaking in node's javascript bootstrapper code.
Previously I've been able to set breakpoints in node bootstrapper code
and then restart the debugging session and those breakpoints would be
hit, but I don't seem to be able to do so anymore. Having this option
would allow me to use this option and then step through or add more
break points as needed.
PR-URL: https://github.com/nodejs/node/pull/20819
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Implement `MessagePort` and `MessageChannel` along the lines of
the DOM classes of the same names. `MessagePort`s initially
support transferring only `ArrayBuffer`s.
Thanks to Stephen Belanger for reviewing this change in its
original form, to Benjamin Gruenbaum for reviewing the
added tests in their original form, and to Olivia Hugger
for reviewing the documentation in its original form.
Refs: https://github.com/ayojs/ayo/pull/98
PR-URL: https://github.com/nodejs/node/pull/20876
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Shingo Inoue <leko.noor@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: John-David Dalton <john.david.dalton@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
