startup snapshot integration in packaging solutions

[joyeecheung]

The recently landed build-time user-land snapshot is related to packaging solutions (e.g. pkg, nexe) in that if the user puts all the resources (modules, assets) in the snapshot, the compiled binary is a single-executable containing a bundle of user code, similar to what these packaging solutions produce, only that

1. We do not provide APIs for the user to specify the run-time entry point in the snapshot entry point yet (it's a WIP), so for now you still have to start the deserialized app with another JS entry point script (i.e. you need to have two files to get it up and running)
2. For now with these packaging solutions you'd usually still need to parse/execute some initialization code before the app is up and running, while with snapshots you can simply deserialize an initialized heap and may not have to execute the initialization code.

On the other hand, the user land snapshot we have right now is still a bit limited - a fair amount of builtins are not yet supported (pending more refactoring), and we still need to collect more user feedback to find states in builtins that might be out-of-sync with the system/native layer when being deserialized from the. snapshot. We also do not support user modules yet (the entry point must contain a bundle of all the modules that's needed by the app). In terms of user-experience, it might still be better to have some kind of tooling that allows users to load assets from the binary as if the assets are in the file system (i.e. virtual file system that packaging solutions provides).

I think that user snapshots in Node.js core is not a complete replacement of these packaging solutions (unless we decide to provide an "official" solution ourselves, but still packaging is different from just snapshotting), but rather it's something that packaging solutions can make use of (i.e. they can build a snapshot into the packaged binary too, while providing features like virtual file systems or compression of assets for a better user experience). So this is an issue to gather ideas and feedback, etc.

Refs: #42566

[mhdawson]

Thanks for the perspective. If I understand correctly the suggestion is that startup snapshots are another tool that might be used in a Single Executable application to speed up startup, but not the way to build a Single Executable application. That makes sense to me.

[addaleax]

@joyeecheung As you may know, we’re trying to use startup snapshots in our own packaging solution. This actually works very nicely for the most part, but we have run into the issue that we can’t distribute packaged SEAs with snapshots as easily because the ScriptCompiler::CachedDataVersionTag() values can mismatch just based on CPU features.

Would it make sense to add a snapshotting mode in which we don’t pass FunctionCodeHandling::kKeep and in return get a snapshot that can be used regardless of available CPU features?

[joyeecheung]

Would it make sense to add a snapshotting mode in which we don’t pass FunctionCodeHandling::kKeep and in return get a snapshot that can be used regardless of available CPU features?

I am thinking about adding some kind of configuration API in v8.startupSnapshot, which allows users to configure this (probably makes sense to support a similar JSON config via command line, or a bunch of corresponding flags in the embedder API too). Another thing that also came up was the ability to disable warnings for unsupported modules after snapshot deserialization. Will probably have some sketch soon.

[addaleax]

@joyeecheung That sounds awesome, yes! Please let me know if I can do something to help, this is probably the kind of thing I could spend some of my regular work time on 🙂

[joyeecheung]

Actually on the particular issue about cpu features, after some discussions I believe it can just be ignored in the code cache version computation, so I uploaded https://chromium-review.googlesource.com/c/v8/v8/+/4905290 to remove it