-
Notifications
You must be signed in to change notification settings - Fork 30.3k
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -25,7 +25,8 @@ const { | |
ContextifyScript, | ||
makeContext, | ||
isContext: _isContext, | ||
compileFunction: _compileFunction | ||
compileFunction: _compileFunction, | ||
createCacheForFunction | ||
} = internalBinding('contextify'); | ||
const { callbackMap } = internalBinding('module_wrap'); | ||
const { | ||
|
@@ -390,17 +391,26 @@ function compileFunction(code, params, options = {}) { | |
} | ||
}); | ||
|
||
return _compileFunction( | ||
const fn = _compileFunction( | ||
code, | ||
filename, | ||
lineOffset, | ||
columnOffset, | ||
cachedData, | ||
produceCachedData, | ||
parsingContext, | ||
contextExtensions, | ||
params | ||
); | ||
|
||
if (produceCachedData) { | ||
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 commentThe 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 commentThe 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 commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So @devsnek and @jdalton support exposing this as part of the As of removing the cache production part inside |
||
} | ||
} | ||
|
||
return 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.
i would rather the could just call this manually. we've learned from vm.Script that
produceCachedData
isn't a very good modelThere 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.