| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -0,0 +1,38 @@ | |||
| 1 | + # Node.js code cache builder | ||
| 2 | + | ||
| 3 | + This is the V8 code cache builder of Node.js. It pre-compiles all the | ||
| 4 | + JavaScript native modules of Node.js and serializes the code cache (including | ||
| 5 | + the bytecodes) that will be embeded into the Node.js executable. When a Node.js | ||
| 6 | + JavaScript native module is `require`d at runtime, Node.js can deserialize from | ||
| 7 | + the code cache instead of parsing the source code and generating the bytecode | ||
| 8 | + for it before execution, which should reduce the load time of these JavaScript | ||
| 9 | + native modules. | ||
| 10 | + | ||
| 11 | + ## How it's built and used | ||
| 12 | + | ||
| 13 | + The code cache builder is built with the `mkcodecache` target in `node.gyp` | ||
| 14 | + when `node_use_node_code_cache` is set to true, which is currently done by | ||
| 15 | + default. | ||
| 16 | + | ||
| 17 | + In the default build of the Node.js executable, to embed the V8 code cache of | ||
| 18 | + the native modules into the Node.js executable, `libnode` is first built with | ||
| 19 | + these unresolved symbols: | ||
| 20 | + | ||
| 21 | + - `node::native_module::has_code_cache` | ||
| 22 | + - `node::native_module::NativeModuleEnv::InitializeCodeCache` | ||
| 23 | + | ||
| 24 | + Then the `mkcodecache` executable is built with C++ files in this directory, | ||
| 25 | + as well as `src/node_code_cache_stub.cc` which defines the unresolved symbols. | ||
| 26 | + | ||
| 27 | + `mkcodecache` is run to generate a C++ file | ||
| 28 | + `<(SHARED_INTERMEDIATE_DIR)/node_code_cache.cc` that is similar to | ||
| 29 | + `src/node_code_cache_stub.cc` in structure, but contains the code cache data | ||
| 30 | + written as static char array literals. Then `libnode` is built with | ||
| 31 | + `node_code_cache.cc` to produce the final Node.js executable with the code | ||
| 32 | + cache data embedded. | ||
| 33 | + | ||
| 34 | + For debugging, Node.js can be built without code cache if | ||
| 35 | + `--without-node-code-cache` is passed to `configure`. Note that even if the | ||
| 36 | + code cache is not pre-compiled and embedded into the Node.js executable, the | ||
| 37 | + internal infrastructure is still used to share code cache between the main | ||
| 38 | + thread and worker threads (if there is any). | ||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -0,0 +1,42 @@ | |||
| 1 | + # Node.js startup snapshot builder | ||
| 2 | + | ||
| 3 | + This is the V8 startup snapshot builder of Node.js. Not to be confused with | ||
| 4 | + V8's own snapshot builder, which builds a snapshot containing JavaScript | ||
| 5 | + builtins, this builds a snapshot containing Node.js builtins that can be | ||
| 6 | + deserialized on top of V8's own startup snapshot. When Node.js is launched, | ||
| 7 | + instead of executing code to bootstrap, it can deserialize the context from | ||
| 8 | + an embedded snapshot, which readily contains the result of the bootstrap, so | ||
| 9 | + that Node.js can start up faster. | ||
| 10 | + | ||
| 11 | + Currently only the main context of the main Node.js instance supports snapshot | ||
| 12 | + deserialization, and the snapshot does not yet cover the entire bootstrap | ||
| 13 | + process. Work is being done to expand the support. | ||
| 14 | + | ||
| 15 | + ## How it's built and used | ||
| 16 | + | ||
| 17 | + The snapshot builder is built with the `node_mksnapshot` target in `node.gyp` | ||
| 18 | + when `node_use_node_snapshot` is set to true, which is currently done by | ||
| 19 | + default. | ||
| 20 | + | ||
| 21 | + In the default build of the Node.js executable, to embed a V8 startup snapshot | ||
| 22 | + into the Node.js executable, `libnode` is first built with these unresolved | ||
| 23 | + symbols: | ||
| 24 | + | ||
| 25 | + - `node::NodeMainInstance::GetEmbeddedSnapshotBlob` | ||
| 26 | + - `node::NodeMainInstance::GetIsolateDataIndexes` | ||
| 27 | + | ||
| 28 | + Then the `node_mksnapshot` executable is built with C++ files in this | ||
| 29 | + directory, as well as `src/node_snapshot_stub.cc` which defines the unresolved | ||
| 30 | + symbols. | ||
| 31 | + | ||
| 32 | + `node_mksnapshot` is run to generate a C++ file | ||
| 33 | + `<(SHARED_INTERMEDIATE_DIR)/node_snapshot.cc` that is similar to | ||
| 34 | + `src/node_snapshot_stub.cc` in structure, but contains the snapshot data | ||
| 35 | + written as static char array literals. Then `libnode` is built with | ||
| 36 | + `node_snapshot.cc` to produce the final Node.js executable with the snapshot | ||
| 37 | + data embedded. | ||
| 38 | + | ||
| 39 | + For debugging, Node.js can be built without Node.js's own snapshot if | ||
| 40 | + `--without-node-snapshot` is passed to `configure`. A Node.js executable | ||
| 41 | + with Node.js snapshot embedded can also be launched without deserializing | ||
| 42 | + from it if the command line argument `--no-node-snapshot` is passed. | ||
| Back | FazBrowse Home | New Git URL |
0 commit comments