-
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
vm: add createCacheForFunction #24069
Conversation
Remove caching logic from the CompileFunction binding from the ContextifyScript class, moving the caching logic to the JS-layer for vm.compileFunction (using the CreateCacheForFunction binding).
parsingContext, | ||
contextExtensions, | ||
params | ||
); | ||
|
||
if (produceCachedData) { |
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.
i would rather the could just call this manually. we've learned from vm.Script that produceCachedData
isn't a very good model
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.
@devsnek that could be done. A couple of things:
-
That'll force us to make this an API method.
vm.compileFunction
used to do that, and people should be allowed to fallback to the original without breakage. -
That'll be a breaking change for
vm.compileFunction
.
Perhaps I could do that in a separate semver-major
PR? That said, I'm still not 100% convinced that this would be a good idea in the first place.
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.
The returned values of vm.compileFunction are neither documented or tested, and it’s only been released since 10.11 (10.10?) I would say it should probably be safe to deprecate the option in 11
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.
Also given how the returned values are used, does it actually break anyone if the cache is not generated? If we only return the function as-is, then cachedDataProduced and cachedData will always be undefined which is not that different from “the cache generation always fail”, but the users (if they exist) should always prepare to handle that case in the first place (provided they actually guess what those values are even when there are no documentations). The only exception that I can think of is our code cache generator but that’s just tooling, not any production code or anything and I don’t think this should be handled as errors in a non-tooling situation...
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.
(The comments above are orthogonal to this PR, BTW, but if vm.compileFunction does not use it, and it’s not exposed as an API either, I couldn’t see why we are adding a binding that is not used...)
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.
The key question is how we should handle the absence of cached data. Should it be seen as an error or a normal state? My inclination is to treat it as a normal state for non-tooling use cases, as it's unclear how extensively these values have been used in production code.
I support the idea of a separate semver-major PR to address this and consider making produceCachedData an API method. This approach provides clarity and a smoother transition for users, especially in scenarios where the use of these values is minimal.
Giving this a bit more thought...maybe this should be placed under v8, as code cache is a v8 thing - conceptually for other vms this could be a noop if they don’t have an equivalent... |
@ryzokuken Is this still being worked on? |
@joyeecheung @ryzokuken, echoing @Trott's curiosity; excited to get this work landed because it moves us closer to being able to simplify test coverage in Node.js. |
@bcoe I was out of town for a conference and other events for more than two weeks. Will jump onto these now. |
Pinging since #21573 was merged and this PR might have renewed energy. |
const cache = createCacheForFunction(fn); | ||
fn.cachedDataProduced = cache !== undefined; | ||
if (fn.cachedDataProduced) { | ||
fn.cachedData = cache; |
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.
i can imagine this making people need to delete the prop after grabbing it if they want to pass the resulting function around. i'm not 100% sure what a better interface would be but i think we should brainstorm more.
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 has been out since v10, though this has not been tested nor documented. We'll probably still need a deprecation cycle if we want to replace this with something else.
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.
i think we also need to allow this to run after the function has been called. we might need to do something like vm.createCodeCacheForFunction(fn)
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.
So @devsnek and @jdalton support exposing this as part of the vm
API, unless I'm wrong? That is complete fine by me, I was actually planning of proposing that myself.
As of removing the cache production part inside vm.compileFunction
, I honestly don't know. Idk if going through the deprecation cycle is worth it, but if everyone else feels it is a great idea to drop the prop, I have no real objections backed with logic.
I'm cleaning out a few old PRs 🧹. I'm closing this due to inactivity. Please re-open if needed! |
Hi @fhinkel! Thanks for the ping. @joyeecheung did you already fix this? If not, I could take a stab. |
Ping @joyeecheung (see question above) |
8ae28ff
to
2935f72
Compare
Ping @ryzokuken and @joyeecheung ... looked like this has stalled completely and needs an update. |
Closing due to lack of continued activity. Can reopen if it ends up being revisited |
@jasnell apologies, I haven't had a lot of time lately, but I do intend to finish this. |
@ryzokuken do you still intend to finish this? |
@bnb sorry about that, I'll try to get back to it over the weekend. |
Does #35375 (comment) affect this? |
I have no clue. @devsnek wdyt? |
it's a different cache. it shouldn't stop this from landing afaik |
Great, then I'll start by rebasing. |
Closing due to lack of continued activity. Can reopen if it ends up being revisited. |
TODO:
/cc @joyeecheung @devsnek