src: reset process.versions during pre-execution

[richardlau]

Reset process.versions during pre-execution so that it reflects the versions at run-time rather than when the snapshot was taken.

Fixes: #51007 (comment)

---

I'm not sure there's an easy way to test this currently in the CI -- it requires Node.js to be built against a dynamically linked library (e.g. zlib[1]) at one version and then run against a different, ABI-compatible version so that the snapshot has one version of the dependency recorded but Node.js is actually running with a different one.

cc @joyeecheung -- re. #51007 (comment) -- it seemed easier to reset the entire process.versions object rather than checking each individual entry (and also meant I could extract and reuse the setting code).

[1]: OpenSSL would be another, but there's a separate bug with obtaining the version of OpenSSL that I'll open another PR for.

[joyeecheung]

Slightly concerned about the runtime overhead of this, since the process.versions have quite a few entries now, but it might not be a big deal, started https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1569/ to find out

[richardlau]

Slightly concerned about the runtime overhead of this, since the process.versions have quite a few entries now, but it might not be a big deal, started https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1569/ to find out

19:12:40                                                                                           confidence improvement accuracy (*)   (**)  (***)
19:12:40 misc/startup-core.js count=30 mode='process' script='benchmark/fixtures/require-builtins'          *     -0.36 %       ±0.31% ±0.42% ±0.54%
19:12:40 misc/startup-core.js count=30 mode='process' script='test/fixtures/semicolon'                             0.65 %       ±3.07% ±4.08% ±5.31%
19:12:40 misc/startup-core.js count=30 mode='process' script='test/fixtures/snapshot/typescript'          ***      0.28 %       ±0.04% ±0.06% ±0.08%
19:12:40 misc/startup-core.js count=30 mode='worker' script='benchmark/fixtures/require-builtins'         ***     -0.47 %       ±0.24% ±0.33% ±0.42%
19:12:40 misc/startup-core.js count=30 mode='worker' script='test/fixtures/semicolon'                             -0.16 %       ±0.46% ±0.61% ±0.79%
19:12:40 misc/startup-core.js count=30 mode='worker' script='test/fixtures/snapshot/typescript'                    0.17 %       ±0.41% ±0.54% ±0.71%
19:12:40 
19:12:40 Be aware that when doing many comparisons the risk of a false-positive
19:12:40 result increases. In this case, there are 6 comparisons, you can thus
19:12:40 expect the following amount of false-positive results:
19:12:40   0.30 false positives, when considering a   5% risk acceptance (*, **, ***),
19:12:40   0.06 false positives, when considering a   1% risk acceptance (**, ***),
19:12:40   0.01 false positives, when considering a 0.1% risk acceptance (***)

[nodejs-github-bot]

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

[richardlau]

@joyeecheung does the benchmark result address your overhead concerns?

[joyeecheung]

It does show that this has a performance impact although it’s limited so far - but might be bigger as we continue to add dependencies. Ideally I think it would be better to reset the object via a snapshotted v8::ObjectTemplate with lazy data properties (so the specific version entries will be slower to access on first read but otherwise the performance overhead of creating a new object is marginal). But that can be done in a follow up.

[nodejs-github-bot]

Landed in 2cb3504