-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bootstrap: support more builtins in the embedded code cache #44018
Conversation
Review requested:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This pattern is more static and cleaner.
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.
Rebased to resolve the merge conflict |
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. PR-URL: #44018 Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
Landed in 06f5d45 |
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. PR-URL: #44018 Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
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. PR-URL: #44018 Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
@joyeecheung I am late to the party, but aren't the new |
@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… |
@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 |
Isn't this already the fact of how we define the function parameters and how we invoke functions with arguments? |
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. |
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. PR-URL: nodejs#44018 Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
This patch:
on module IDs. This allows us to compile more builtins when
generating the embedded bootstrap, including
compiled as a regular built-in module, unlike other scripts
in lib/internal/bootstrap
making it a function-wrapper-based global to reduce number of
special cases.