GeezerVison

Review requested:

• @nodejs/startup

Thanks for doing this!

add some tooling to process the inputs

I personally really like this approach. I've opened a discussion in nodejs/single-executable#58, so that we can have a decision on this.

Rebased using the new SnapshotBuilder::Generate() overload added in #48242 and added a test. Will add more doc and tests next week but the implementation is there.

Rebased using the new SnapshotBuilder::Generate() overload added in #48242 and added a test. Will add more doc and tests next week but the implementation is there.

What's the difference between snapshot and code cache (bytenode)?

What's the difference between snapshot and code cache (bytenode)?

If you have a bunch of top level code with a bunch of inner functions, usually when building the snapshot you run all the top level code and compile some of the inner functions, the snapshot contains the state of the heap after the top-level code is run and the bytecode of the inner functions that would be run again later. When deserializing the snapshot, you deserialize the state of an initialized heap (so there is no need to run the top-level code at all), and maybe later when the application invokes some of the inner functions, V8 deserialize the bytecode in the snapshot during the compilation of the function to speed things up. If there's just the code cache, what usually happens is that you have the bytecode of the top-level code and some inner functions. At runtime V8 deserializes the bytecode in the code cache to speed up compilation of the top-level code, but it still needs to run the top-level code to set up the heap.

CI: https://ci.nodejs.org/job/node-test-pull-request/52256/

CI is almost green (with some flakes that look irrelevant). Can I have some reviews please? @nodejs/single-executable thanks!

If you have a bunch of top level code with a bunch of inner functions, usually when building the snapshot you run all the top level code and compile some of the inner functions, the snapshot contains the state of the heap after the top-level code is run and the bytecode of the inner functions that would be run again later. When deserializing the snapshot, you deserialize the state of an initialized heap (so there is no need to run the top-level code at all), and maybe later when the application invokes some of the inner functions, V8 deserialize the bytecode in the snapshot during the compilation of the function to speed things up. If there's just the code cache, what usually happens is that you have the bytecode of the top-level code and some inner functions. At runtime V8 deserializes the bytecode in the code cache to speed up compilation of the top-level code, but it still needs to run the top-level code to set up the heap.

Thank you @joyeecheung for your detailed explain :-) So, if I understood it correctly, a snapshoot is a combo of a module compiled and bytecode functions plus heap after executing the module top level code, while the code cache only have the bytecode of all the module code, isn't it?

So, if I understood it correctly, a snapshoot is a combo of a module compiled and bytecode functions plus heap after executing the module top level code, while the code cache only have the bytecode of all the module code, isn't it?

Roughly yes. V8 does not always emit bytecode for all the code it encounters (e.g. inner-inner functions are usually just parsed for syntax checks, but no bytecode is generated until they actually get executed). In some cases snapshots may contain more bytecode if during the snapshot building cases these functions are invoked.

V8 does not always emit bytecode for all the code it encounters

Maybe bytenode is forcing its generation? Could it of our interest when generating the snapshots, so no Javascript code is included in it?

@RaisenTen can you please confirm you are comfortable with this based on nodejs/single-executable#58 and nodejs/single-executable#58 (reply in thread) landing

Could it of our interest when generating the snapshots, so no Javascript code is included in it?

I would say that's not always a win, you could also have a lot of dead code in that application, or code that never gets run in many use cases, then eagerly generating code may result in a memory/size overhead that's not always worth it. As a configurable thing that might be useful though.

I can try to take a look day after tomorrow. (I'll be traveling pretty much the entire day tomorrow)

As a configurable thing that might be useful though.

Agree on that 👍🏻

CI: https://ci.nodejs.org/job/node-test-pull-request/52874/

Landed in ac34e75