build: tracking issue for V8 code cache intergration

[joyeecheung]

Following up on #21405

• Better integrity check when using the code cache in NativeModule.prototype.compile (right now SerializedCodeData::SourceHash returns source->length()) e.g. calculating the checksums of the source code in both js2c and the code cache generator and compare them before using the cache. See build: speed up startup with V8 code cache #21405 (comment) simply relying on V8 to do the checks is fine
• build: create V8 code cache after script is run #21567: Use script.createCachedData to generate the code cache after the builtin modules have runInThisContext(), so that the cache of the lazily compiled inner functions are also included (right now only the top level function is included in the cache),see build: speed up startup with V8 code cache #21405 (comment) . We may need to include the code cache generator in core or expose the scripts to user land.
• Cache internal/bootstrap/loaders.js and internal/bootstrap/node.js (these two are compiled in C++): src: use NativeModuleLoader to compile all the bootstrappers #24775
• (might be related if we still use JS to generate the cache) Add support for the full range of CompileOptions (and possibly NoCacheReason) to ContextifyScript/vm.Script it's not using the JS land function anymore

Long-term action items

• Refactors node.js and/or node.cc so that we can create something like a mkcodecache (similar to mksnapshot) target instead of generating the code cache with a user-land JS script tools: implement mkcodecache as an executable #27135
• Resolve the dependency issue automatically in build files: make sure when the inputs to node_js2c is modified, the cache will be regenerated and compiled the next time Node.js is built with node_code_cache_path build,tools: use mkcodecache to add code cache to the binaries #27161
• Integrate the code-cached build into default workflow and releases and make sure a test like test-code-cache is run in the release CI to make sure we don't have a ~100% performance regression of startup time: build: build release/CI on non-Windows with code cache #22934 build,tools: use mkcodecache to add code cache to the binaries #27161

[joyeecheung]

cc @devsnek @hashseed @TimothyGu

[joyeecheung]

BTW: I explored the idea of generating the code cache after the script has been run and it does not seem to make much difference:

See benchmark results

                       confidence improvement accuracy (*)   (**)  (***)
 misc/startup.js dur=1                -0.18 %       ±1.89% ±2.52% ±3.28%

Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case there are 1 comparisons, you can thus
expect the following amount of false-positive results:
  0.05 false positives, when considering a   5% risk acceptance (*, **, ***),
  0.01 false positives, when considering a   1% risk acceptance (**, ***),
  0.00 false positives, when considering a 0.1% risk acceptance (***)

[hashseed]

As a sanity check, does the code cache size change significantly if you create it after the script has been run?

How many functions do you see lazily compiled with both variants (creating cache data before and after execution) with --trace-lazy?

[hashseed]

Also, I don't think you need NoCacheReason. It's only purpose is to provide data for Chrome's telemetry.

[joyeecheung]

@hashseed I opened #21567 so there is something concrete to discuss

[devsnek]

@joyeecheung when the files that node_js2c depends on change the makefile should run it again automatically right?

[joyeecheung]

@devsnek It is supposed to. It doesn't (that's in the TODO list in the OP, feel free to pick it up).

[joyeecheung]

A few notes on better hash checks of the code cache: in theory it should be possible to make sure node_javascript.cc and node_code_cache.cc are in sync by performing a static_assert of the hashes in C++ (generated by js2c.py and generate_code_cache.js). But since the two C++ files are generated separately, it's still possible that the generated static_assert are out of sync with the sources no matter where you put them. The only way to make sure they are in sync is to make sure node_javascript.cc and node_code_cache.cc are generated together - either in one script or in one build step. The best way to do this that I can think of is still to make js2c.py and generate_code_cache.js two binaries instead of two scripts that relie on Python/Node.js, and that requires some refactoring.