fbc52e5729The term "native module" dates back to some of the oldest code in the code base. Within the context of Node.js core it usually refers to modules that are native to Node.js (e.g. fs, http), but it can cause confusion for people who don't work on this part of the code base, as "native module" can also refer to native addons - which is even the case in some of the API docs and error messages. This patch tries to make the usage of these terms more consistent. Now within the context of Node.js core: - JavaScript scripts that are built-in to Node.js are now referred to as "built-in(s)". If they are available as modules, they can also be referred to as "built-in module(s)". - Dynamically-linked shared objects that are loaded into the Node.js processes are referred to as "addons". We will try to avoid using the term "native modules" because it could be ambiguous. Changes in this patch: File names: - node_native_module.h -> node_builtins.h, - node_native_module.cc -> node_builtins.cc C++ binding names: - `native_module` -> `builtins` `node::Environment`: - `native_modules_without_cache` -> `builtins_without_cache` - `native_modules_with_cache` -> `builtins_with_cache` - `native_modules_in_snapshot` -> `builtins_in_cache` - `native_module_require` -> `builtin_module_require` `node::EnvSerializeInfo`: - `native_modules` -> `builtins `node::native_module::NativeModuleLoader`: - `native_module` namespace -> `builtins` namespace - `NativeModuleLoader` -> `BuiltinLoader` - `NativeModuleRecordMap` -> `BuiltinSourceMap` - `NativeModuleCacheMap` -> `BuiltinCodeCacheMap` - `ModuleIds` -> `BuiltinIds` - `ModuleCategories` -> `BuiltinCategories` - `LoadBuiltinModuleSource` -> `LoadBuiltinSource` `loader.js`: - `NativeModule` -> `BuiltinModule` (the `NativeModule` name used in `process.moduleLoadList` is kept for compatibility) And other clarifications in the documentation and comments. PR-URL: https://github.com/nodejs/node/pull/44135 Backport-PR-URL: https://github.com/nodejs/node/pull/45663 Fixes: https://github.com/nodejs/node/issues/44036 Reviewed-By: Jacob Smith <jacob@frende.me> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Jan Krems <jan.krems@gmail.com>
38 lines
1.8 KiB
Markdown
38 lines
1.8 KiB
Markdown
# Node.js code cache builder
|
|
|
|
This is the V8 code cache builder of Node.js. It pre-compiles all the
|
|
JavaScript native modules of Node.js and serializes the code cache (including
|
|
the bytecodes) that will be embedded into the Node.js executable. When a Node.js
|
|
JavaScript native module is `require`d at runtime, Node.js can deserialize from
|
|
the code cache instead of parsing the source code and generating the bytecode
|
|
for it before execution, which should reduce the load time of these JavaScript
|
|
native modules.
|
|
|
|
## How it's built and used
|
|
|
|
The code cache builder is built with the `mkcodecache` target in `node.gyp`
|
|
when `node_use_node_code_cache` is set to true, which is currently done by
|
|
default.
|
|
|
|
In the default build of the Node.js executable, to embed the V8 code cache of
|
|
the native modules into the Node.js executable, `libnode` is first built with
|
|
these unresolved symbols:
|
|
|
|
- `node::builtins::has_code_cache`
|
|
- `node::builtins::NativeModuleEnv::InitializeCodeCache`
|
|
|
|
Then the `mkcodecache` executable is built with C++ files in this directory,
|
|
as well as `src/node_code_cache_stub.cc` which defines the unresolved symbols.
|
|
|
|
`mkcodecache` is run to generate a C++ file
|
|
`<(SHARED_INTERMEDIATE_DIR)/node_code_cache.cc` that is similar to
|
|
`src/node_code_cache_stub.cc` in structure, but contains the code cache data
|
|
written as static char array literals. Then `libnode` is built with
|
|
`node_code_cache.cc` to produce the final Node.js executable with the code
|
|
cache data embedded.
|
|
|
|
For debugging, Node.js can be built without code cache if
|
|
`--without-node-code-cache` is passed to `configure`. Note that even if the
|
|
code cache is not pre-compiled and embedded into the Node.js executable, the
|
|
internal infrastructure is still used to share code cache between the main
|
|
thread and worker threads (if there is any).
|