Replies: 2 comments 8 replies
-
|
I think the reason why we opted for injecting the original JS file was because of simplicity but of course that can be changed since SEA is experimental. V8 snapshot
I'm assuming you're referring to https://nodejs.org/api/cli.html#--build-snapshot? The docs mention:
Since a regular JS file supports all built-in modules and snapshots don't, it means that using the original JS file would have more capabilities for now. Now let's look at the advantages this has over using a JS file:
I don't think that's always true. Take a look at this example of using a tiny JS file: require('v8').startupSnapshot.setDeserializeMainFunction(() => {
const { stat } = require('fs/promises');
(async () => {
console.log(await stat('./index.js'));
})()
});If I create a snapshot file using du -sh index.js snapshot.blob
4.0K index.js
4.0M snapshot.blobI tried doing this on a real world js bundle, something we use at postman, which is 14 MB and building snapshots don't work for that because it relies on certain built-in modules that aren't supported in snapshots, like tty, child_process, vm, https, http, tls, readline, http2. Also, it seems like building / using a snapshot fails when we use the
That's true.
If you inspect the snapshot blob in the example above, you'll be able to see the exact source code (you can search for Usage - We can use this once we have a way to bake CLI options and a VFS (not implemented yet but there are plans to do that), so that we can bake something like V8 code cache
I haven't dug into hermes yet but here's my assessment on the advantages of using the bytenode approach (which uses a code cache, not a snapshot, which is different) over a plan JS file:
For small files, like the one I showed above, the sizes are pretty much the same but it's slightly higher for the output file (specifically, 103 bytes for the input and 1008 bytes for the output). Doesn't seem to be true for a large JS file either: du -sh file.cjs file..jsc
14M index.js
17M index.jscSo I wouldn't consider this to be an advantage.
True.
According to https://swarm.ptsecurity.com/how-we-bypassed-bytenode-and-decompiled-node-js-bytecode-in-ghidra, it seems like something that can be reverse engineered? I can also think of a disadvantage: I tried checking if exception info, like line number is preserved and it looks like that doesn't happen in bytenode, i.e., the stack trace of exceptions show that the source of the error is at Usage - I think this can be used already if you inject an entry point that uses bytenode's API - |
Beta Was this translation helpful? Give feedback.
-
This depends on the file specifically - the snapshot includes what has to be inside a Node.js heap + application states (note that it's serialized application state i.e. the result of running code, not code itself). So if the source file is smaller than the size of a basic Node.js heap, then it's going to be smaller (the snapshot of an empty script is 3.7MB i.e. the basic Node.js heap needs at least 3.7MB of space in the serialized blob. then what's on top are the application states). But generally source files can be bigger (because they are text). Take |
Beta Was this translation helpful? Give feedback.
-
|
Also this is the same regarding code cache - take the TypeScript bundle again for example, the code cache is around 1.6MB (you can already check this out with |
Beta Was this translation helpful? Give feedback.
-
This is the sacrifice that the application has to make for now if they want code cache instead of source text, not in addition to source text. V8 relies on reparsing the source to generate proper source positions. But it's also a common sacrifice that binaries make for smaller sizes (for example when you crash a release build of Chrome, it's very unlikely that you get to see any useful symbols in the stack trace, because they are mostly stripped away). Though I think it might be solvable by somehow plumbing additional source text to V8, like how PDB files work. |
Beta Was this translation helpful? Give feedback.
-
|
Option to run with a source map file, passed as parameter or environment variable? |
Beta Was this translation helpful? Give feedback.
-
|
I wonder if @joyeecheung has more thoughts on this because she's leading the snapshots work? Also, cc @nodejs/single-executable |
Beta Was this translation helpful? Give feedback.
-
|
I don't see snapshot as replacements of JS entry points - they can be both supported. We could add something that tells the binary to either:
|
Beta Was this translation helpful? Give feedback.
-
|
I can give 2 a try (I think it should be fairly easy to implement). But I do have a question, where is this embedded snapshot supposed to be? Does it go into the |
Beta Was this translation helpful? Give feedback.
-
|
POC here nodejs/node#46824 |
Beta Was this translation helpful? Give feedback.
-
|
Has there been any improvement with the PoC? On my use case, I have followed the path with bytenode (code caches instead of snapshots, sorry), and was able to create a tool to generate them fully for both executables and libraries, only missing part is to be able to include them in the Node.js binary (and the VFS for files that can't be bundled) to make them fully standalone :-) |
Beta Was this translation helpful? Give feedback.
-
Since we are creating a single executable application, source code is not intended to be modified, so it doesn't makes sense to just add a Javascript bundle to the Node.js executable. What not add instead a v8 snapshot? Code would be the same, but final file size will be smaller, start time shorter, and since we are going to target just the exact version of v8 included in the attached Node.js binary, there would not be runtime incompatibilities, in addition to make it more difficult to disassemble the original Javascript source code. There's similar previous aproaches with bytenode and Hermes engine.
Beta Was this translation helpful? Give feedback.
All reactions