bootstrap: support more builtins in the embedded code cache

[joyeecheung]

This patch:

• Make NativeModuleLoader::LookupAndCompile() detect parameters based
  on module IDs. This allows us to compile more builtins when
  generating the embedded bootstrap, including
  • internal/per_context/*
  • internal/bootstrap/*
  • internal/main/*
• Move pre_execution.js to lib/internal/process as it needs to be
  compiled as a regular built-in module, unlike other scripts
  in lib/internal/bootstrap
• Move markBootstrapComplete() to the performance binding instead of
  making it a function-wrapper-based global to reduce number of
  special cases.

[nodejs-github-bot]

Review requested:

• @nodejs/modules
• @nodejs/startup

[nodejs-github-bot]

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

[legendecas]

This pattern is more static and cleaner.

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[joyeecheung]

Rebased to resolve the merge conflict

[nodejs-github-bot]

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

[joyeecheung]

Landed in 06f5d45

[mmomtchev]

@joyeecheung I am late to the party, but aren't the new ExecuteBootstrapper parameters more error-prone since they rely on an order that is determined by a different file - I mean that list in src/node_builtins.cc? Have you considered simply having one and only full list of all parameters that are to be received by all bootstrapping scripts? The performance hit would be minimal or is there another reason?

[joyeecheung]

@mmomtchev The parameters are guarded by the linter and when passed wrong it’s likely to trigger an error early in the bootstrap process. It’s inevitable that some of the arguments are just unavailable to some scripts (because they are not initialized yet or aren’t supposed to be accessible), it would be nicer to see a ReferenceError instead of a TypeError (something is undefined) in that case. Personally I would find it more error-prone if per-context scripts get an undefined internalBinding or process…

[mmomtchev]

@joyeecheung You can always skip those values that are undefined - you check if it has been initialised and then add it only it has a value. What I meant is that the part that adds the names and the part that adds the values are in two different files and they must have the exactly same order. Isn't it possible to generate the values in src/node_builtins.cc? Or maybe to pass pairs of name/values?

[legendecas]

What I meant is that the part that adds the names and the part that adds the values are in two different files and they must have the exactly same order.

Isn't this already the fact of how we define the function parameters and how we invoke functions with arguments?

[joyeecheung]

Isn't it possible to generate the values in src/node_builtins.cc? Or maybe to pass pairs of name/values?

I gave it a try in #44488 - some of the values can be generated, but not all of them (e.g. the per-context arguments, the ones generated by the JS-land loader). And as @legendecas pointed out that's just how JS functions work, it's sometimes possible to place the definition and the callsite closer together, other times you just have to look up the parameters somewhere else and make sure that the arguments passed into it are in the right order.