Skip to content
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

Persist the V8 code cache before spawning a child process #54465

Closed
merceyz opened this issue Aug 20, 2024 · 2 comments
Closed

Persist the V8 code cache before spawning a child process #54465

merceyz opened this issue Aug 20, 2024 · 2 comments
Labels
feature request Issues that request new features to be added to Node.js.

Comments

@merceyz
Copy link
Member

merceyz commented Aug 20, 2024

What is the problem this feature will solve?

NODE_COMPILE_CACHE persists the V8 code cache when the process is terminating which means that if the script spawns itself then that child process wont benefit from the cache.

What is the feature you are proposing to solve the problem?

Persist the V8 code cache before spawning a child process so it can benefit from the cache.

import { execFileSync } from "child_process";

if (process.argv[2] === "foo") {
	console.log("foo");
} else {
	// Persist the V8 code cache
	console.log(execFileSync("node", ["test.mjs", "foo"]).toString());
}

What alternatives have you considered?

No response

@merceyz merceyz added the feature request Issues that request new features to be added to Node.js. label Aug 20, 2024
@github-project-automation github-project-automation bot moved this to Awaiting Triage in Node.js feature requests Aug 20, 2024
@joyeecheung
Copy link
Member

joyeecheung commented Aug 21, 2024

I wonder if we should just provide an API for the user to tell Node.js to persist the cache of modules already loaded (that would be similar to v8.takeCoverage() which flushes the coverage accumulated via NODE_V8_COVERAGE to disk). It can be tricky to persist the cache implicitly for any child process calls - either it needs to be blocking, then it could actually make the child process calls wait for it if the cache is big enough, or it needs to be non-blocking, then it's questionable whether the new child process actually get to pick it up - it might finish startup earlier than the persistence of the cache completes. Only the party spawning the child process knows what is the best for the kind of child process that they are spawning.

Also I am not sure how big of a problem this is - you won't get to pick up the cache the first time this application is launched, but you will get it the second time the application is launched anyway. Both the main and the child processes will pick it up from the same store, so the coverage is only missing for the child processes in the first launch.

@joyeecheung
Copy link
Member

Opened #54971

nodejs-github-bot pushed a commit that referenced this issue Sep 20, 2024
PR-URL: #54971
Fixes: #54770
Fixes: #54465
Reviewed-By: Yagiz Nizipli <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
nodejs-github-bot pushed a commit that referenced this issue Sep 20, 2024
This implements an API for users to intentionally flush the
accumulated compile cache instead of waiting until process
shutdown. It may be useful for application that loads dependencies
first and then either reload itself in other instances, or spawning
other instances that load an overlapping set of its dependencies -
in this case its useful to flush the cache early instead of waiting
until the shutdown of itself.

Currently flushing is triggered by either process
shutdown or user requests. In the future we should simply start the
writes right after module loading on a separate thread, and this method
only blocks until all the pending writes (if any) on the other thread
are finished. In that case, the off-thread writes should finish long
before any attempt of flushing is made so the method would then only
incur a negligible overhead from thread synchronization.

PR-URL: #54971
Fixes: #54770
Fixes: #54465
Reviewed-By: Yagiz Nizipli <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
targos pushed a commit that referenced this issue Oct 4, 2024
This works better in terms of avoiding race conditions.

PR-URL: #54971
Fixes: #54770
Fixes: #54465
Reviewed-By: Yagiz Nizipli <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
targos pushed a commit that referenced this issue Oct 4, 2024
PR-URL: #54971
Fixes: #54770
Fixes: #54465
Reviewed-By: Yagiz Nizipli <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
targos pushed a commit that referenced this issue Oct 4, 2024
This implements an API for users to intentionally flush the
accumulated compile cache instead of waiting until process
shutdown. It may be useful for application that loads dependencies
first and then either reload itself in other instances, or spawning
other instances that load an overlapping set of its dependencies -
in this case its useful to flush the cache early instead of waiting
until the shutdown of itself.

Currently flushing is triggered by either process
shutdown or user requests. In the future we should simply start the
writes right after module loading on a separate thread, and this method
only blocks until all the pending writes (if any) on the other thread
are finished. In that case, the off-thread writes should finish long
before any attempt of flushing is made so the method would then only
incur a negligible overhead from thread synchronization.

PR-URL: #54971
Fixes: #54770
Fixes: #54465
Reviewed-By: Yagiz Nizipli <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
louwers pushed a commit to louwers/node that referenced this issue Nov 2, 2024
This works better in terms of avoiding race conditions.

PR-URL: nodejs#54971
Fixes: nodejs#54770
Fixes: nodejs#54465
Reviewed-By: Yagiz Nizipli <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
louwers pushed a commit to louwers/node that referenced this issue Nov 2, 2024
louwers pushed a commit to louwers/node that referenced this issue Nov 2, 2024
This implements an API for users to intentionally flush the
accumulated compile cache instead of waiting until process
shutdown. It may be useful for application that loads dependencies
first and then either reload itself in other instances, or spawning
other instances that load an overlapping set of its dependencies -
in this case its useful to flush the cache early instead of waiting
until the shutdown of itself.

Currently flushing is triggered by either process
shutdown or user requests. In the future we should simply start the
writes right after module loading on a separate thread, and this method
only blocks until all the pending writes (if any) on the other thread
are finished. In that case, the off-thread writes should finish long
before any attempt of flushing is made so the method would then only
incur a negligible overhead from thread synchronization.

PR-URL: nodejs#54971
Fixes: nodejs#54770
Fixes: nodejs#54465
Reviewed-By: Yagiz Nizipli <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Issues that request new features to be added to Node.js.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants