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

vm: add createCacheForFunction #24069

Closed
wants to merge 4 commits into from

Conversation

ryzokuken
Copy link
Contributor

TODO:
  • Use the binding in vm.compileFunction and family, removing the C++ code that currently handles caching.

/cc @joyeecheung @devsnek

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. vm Issues and PRs related to the vm subsystem. labels Nov 3, 2018
src/node_contextify.cc Outdated Show resolved Hide resolved
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) {
Copy link
Member

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

Copy link
Contributor Author

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:

  1. 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.

  2. 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.

Copy link
Member

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

Copy link
Member

@joyeecheung joyeecheung Nov 5, 2018

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...

Copy link
Member

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...)

Copy link

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.

@joyeecheung
Copy link
Member

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...

@Trott
Copy link
Member

Trott commented Nov 28, 2018

@ryzokuken Is this still being worked on?

@bcoe
Copy link
Contributor

bcoe commented Dec 2, 2018

@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.

@ryzokuken
Copy link
Contributor Author

@bcoe I was out of town for a conference and other events for more than two weeks. Will jump onto these now.

@jdalton
Copy link
Member

jdalton commented Feb 20, 2019

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;
Copy link
Member

@devsnek devsnek Feb 20, 2019

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.

Copy link
Member

@joyeecheung joyeecheung Feb 20, 2019

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.

Copy link
Member

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)

Copy link
Contributor Author

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.

@fhinkel
Copy link
Member

fhinkel commented Oct 28, 2019

I'm cleaning out a few old PRs 🧹. I'm closing this due to inactivity. Please re-open if needed!

@ryzokuken
Copy link
Contributor Author

Hi @fhinkel! Thanks for the ping. @joyeecheung did you already fix this? If not, I could take a stab.

@BridgeAR
Copy link
Member

Ping @joyeecheung (see question above)

@BridgeAR BridgeAR force-pushed the master branch 2 times, most recently from 8ae28ff to 2935f72 Compare May 31, 2020 12:20
@jasnell jasnell added the stalled Issues and PRs that are stalled. label Jun 25, 2020
@jasnell
Copy link
Member

jasnell commented Jun 25, 2020

Ping @ryzokuken and @joyeecheung ... looked like this has stalled completely and needs an update.

@jasnell
Copy link
Member

jasnell commented Jul 6, 2020

Closing due to lack of continued activity. Can reopen if it ends up being revisited

@jasnell jasnell closed this Jul 6, 2020
@ryzokuken ryzokuken reopened this Jul 6, 2020
@ryzokuken
Copy link
Contributor Author

@jasnell apologies, I haven't had a lot of time lately, but I do intend to finish this.

@bnb
Copy link
Contributor

bnb commented Jan 11, 2022

@ryzokuken do you still intend to finish this?

@ryzokuken
Copy link
Contributor Author

@bnb sorry about that, I'll try to get back to it over the weekend.

@SimenB
Copy link
Member

SimenB commented Jan 12, 2022

Does #35375 (comment) affect this?

@ryzokuken
Copy link
Contributor Author

I have no clue. @devsnek wdyt?

@devsnek devsnek marked this pull request as ready for review January 12, 2022 14:29
@devsnek
Copy link
Member

devsnek commented Jan 12, 2022

it's a different cache. it shouldn't stop this from landing afaik

@ryzokuken
Copy link
Contributor Author

Great, then I'll start by rebasing.

@fhinkel
Copy link
Member

fhinkel commented Feb 3, 2024

Closing due to lack of continued activity. Can reopen if it ends up being revisited.

@fhinkel fhinkel closed this Feb 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. test-stale-pr vm Issues and PRs related to the vm subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.