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 Script.createCodeCache() #20300

Conversation

devsnek
Copy link
Member

@devsnek devsnek commented Apr 25, 2018

Closes #20052

/cc @nodejs/vm

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

@devsnek devsnek requested a review from hashseed April 25, 2018 17:24
@nodejs-github-bot nodejs-github-bot added the lib / src Issues and PRs related to general changes in the lib or src directory. label Apr 25, 2018
@devsnek devsnek added vm Issues and PRs related to the vm subsystem. and removed lib / src Issues and PRs related to general changes in the lib or src directory. labels Apr 25, 2018
lib/vm.js Outdated
if (cachedData && !cachedDataWarned) {
process.emitWarning(cachedDataMessage, 'DeprecationWarning', 'DEPXXXX');
cachedDataWarned = true;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this makes this PR semver-major – it might be easier to split the deprecation out?

Also – What’s the motivation for not doing a docs-only deprecation first? Do we actually want a run-time deprecation at any point? It seems like, for cache information, just making them no-ops would be less breakage for users…

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i can remove the runtime dep

Copy link
Member

@jasnell jasnell Apr 27, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The additional of a new throw also makes it semver-major.

Wait, nevermind, this is a check on a new property. Scratch that :-)

@addaleax addaleax added the semver-major PRs that contain breaking changes and should be released in the next major version. label Apr 25, 2018
@devsnek devsnek added semver-minor PRs that contain new features and should be released in the next minor version. and removed semver-major PRs that contain breaking changes and should be released in the next major version. labels Apr 25, 2018
@devsnek devsnek force-pushed the feature/vm-snapshot-on-the-go-anytime-anywhere branch from 0a65658 to d4aa733 Compare April 25, 2018 18:06

Type: Documentation-only

The options `produceCachedData` and `cachedData` have been deprecated. Please use
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 also support splitting the deprecation into a separate PR, so that we can ship this earlier without semver changes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed it to docs only, not sure why I made it runtime 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.

Even as a docs-only deprecation, it should be separated out into a separate commit.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also ... just a nit... s/DEPXXXX/DEP00XX ... the release tooling looks specifically for the DEP00XX pattern to ensure that the codes are properly assigned before release.

env,
reinterpret_cast<const char*>(cached_data->data),
cached_data->length);
args.GetReturnValue().Set(buf.ToLocalChecked());

This comment was marked as resolved.

src/env.h Outdated
V(change_string, "change") \
V(channel_string, "channel") \
V(chunks_sent_since_last_write_string, "chunksSentSinceLastWrite") \
V(code_cache_used_string, "codeCacheUsed") \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an API change. Not sure whether that belongs into a separate PR? Not sure if this would block this PR from going into Node 10 otherwise.

doc/api/vm.md Outdated
* `codeCache` {Buffer} Provides an optional `Buffer` with V8's code cache
data for the supplied source. When supplied, the `codeCacheRejected` value
will be set to either `true` or `false` depending on acceptance of the data
by V8.
* `cachedData` {Buffer} Provides an optional `Buffer` with V8's code cache
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the code cache generated by createCodeCache compatible with cachedData

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. The latter is produced with createCodeCache.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case I’m reluctant to deprecate an older name of the same thing. Actually would rather change createCodeCache to createCachedData or something similar.

@joyeecheung
Copy link
Member

@hashseed Can the code cache generated by a different version of v8 be loaded by another? (My guess is no?)

@hashseed
Copy link
Member

We check a version hash before deserializing. If the version hash mismatches, V8 rejects the cache data.

@joyeecheung
Copy link
Member

@hashseed Thanks. It would be good to document about this (otherwise the user only has a boolean codeCacheRejected without further information or possible cause)

@devsnek
Copy link
Member Author

devsnek commented Apr 27, 2018

I'm going to work on some patches this weekend for v8 to provide more data on what happened with the caches besides just if it was rejected, which should help make this API a bit better

@hashseed
Copy link
Member

Generally agree. Though I think landing the minimal change of adding this new API without adding the reject reason or deprecating the old API would make sense too.

@devsnek devsnek force-pushed the feature/vm-snapshot-on-the-go-anytime-anywhere branch 2 times, most recently from f066d12 to b45e969 Compare April 28, 2018 14:53
Copy link
Member

@TimothyGu TimothyGu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good.

doc/api/vm.md Outdated
-->

Creates a code cache that can be used with the Script constructor's
`cachedData` option. Returns a Buffer. If the code cache cannot be created then

This comment was marked as resolved.

- version: REPLACEME
pr-url: https://github.com/nodejs/node/pull/20300
description: The `produceCachedData` is deprecated in favour of
`script.createCachedData()`

This comment was marked as resolved.

doc/api/vm.md Outdated

Creates a code cache that can be used with the Script constructor's
`cachedData` option. Returns a Buffer. If the code cache cannot be created then
`ERR_CODE_CACHE_CREATION_FAILED` is thrown. This method may be called at any
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hashseed What can possibly lead to failure of creating cached data? It would be helpful here for the documentation.

doc/api/vm.md Outdated
Creates a code cache that can be used with the Script constructor's
`cachedData` option. Returns a Buffer. If the code cache cannot be created then
`ERR_CODE_CACHE_CREATION_FAILED` is thrown. This method may be called at any
time and any number of times.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe also link to the V8 blog post?


if (script.cachedDataProduced)
data = script.cachedData.toString('base64');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The old code should still be tested.

<a id="DEP00XX"></a>
### DEP00XX: vm.Script cached data

Type: Documentation-only
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason this isn't runtime?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TimothyGu Some previous comments on that in #20300 (comment) … for a caching functionality, there is no reason to introduce a runtime deprecation, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i never know when to make something documentation or runtime... do we have some sort of guide on deciding which to do? i always kinda saw documentation as things that are too ingrained in npm packages such that like any project would be spammed if it used a runtime dep

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@devsnek I don’t know if you’ve read it, but https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md#deprecations might help you?

Generally, we should avoid moving directly from a documented feature towards a runtime deprecation. But yes, obviously popularity of a feature has played a role in deciding how fast we move with those steps…

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@addaleax i've seen that but it doesn't really explain when to use them, just how they fit into semver. is the generally expected process that something will do docs -> runtime -> eol?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the generally expected process that something will do docs -> runtime -> eol?

Yes, unless we have reason to deviate from it. But in this case I do think we have reason to do so. :)

@hashseed
Copy link
Member

hashseed commented Apr 29, 2018

These here are possible reject reasons.

@TimothyGu
Copy link
Member

@hashseed I meant possible reasons for failure of creating a code cache, not consuming one :)

@hashseed
Copy link
Member

Oh. Creating may fail if the script is actually an asm.js module or if the debugger is active. The latter can probably be fixed as soon as the debug context has been removed completely.

@jdalton
Copy link
Member

jdalton commented May 28, 2018

Any updates here? What's the status?

@devsnek
Copy link
Member Author

devsnek commented May 28, 2018

@jdalton hashseed is going to backport a bunch of changes to SharedFunctionInfo soonish, this is just waiting for that.

@hashseed
Copy link
Member

Umm.. wait. Which changes am I supposed to backport? I am not aware of anything actionable on my end. Did I drop the ball?

@devsnek
Copy link
Member Author

devsnek commented May 29, 2018

@hashseed a couple weeks ago I emailed you about backporting the changes for this and modules sfi and my understanding from that was you would be backporting the changes. if that's wrong sorry about the misunderstanding 😅

@hashseed
Copy link
Member

I haven't found such an email unfortunately. Do you mean by any chance this change? I'm pessimistic that it will get green light for back porting since this is not a bug fix. We could just float this in Node?

@jdalton
Copy link
Member

jdalton commented Jun 1, 2018

@devsnek Are you cool floating the change into Node?

@devsnek devsnek force-pushed the feature/vm-snapshot-on-the-go-anytime-anywhere branch from ab4284b to c31b520 Compare June 19, 2018 17:59
@jdalton
Copy link
Member

jdalton commented Jun 19, 2018

Okay! :shipit:

@jdalton
Copy link
Member

jdalton commented Jun 21, 2018


assert(cachedData instanceof Buffer);

data = cachedData.toString('base64');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This overwrites data created earlier. Is it possible to test the buffer returned from both produceCachedData and createCachedData?

@jdalton

This comment has been minimized.

@devsnek devsnek force-pushed the feature/vm-snapshot-on-the-go-anytime-anywhere branch from c31b520 to 9db4f30 Compare June 21, 2018 19:16
@jdalton
Copy link
Member

jdalton commented Jun 22, 2018

@addaleax addaleax added the c++ Issues and PRs that require attention from people who are familiar with C++. label Jun 22, 2018
@addaleax
Copy link
Member

CI again just to make sure: https://ci.nodejs.org/job/node-test-commit/19379/

@addaleax addaleax added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jun 22, 2018
@jdalton
Copy link
Member

jdalton commented Jun 22, 2018

While experimenting with createCachedData() locally I noticed the produced buffers are roughly the same size as the old cachedData results even when calling createCachedData() after running the scripts (~800 modules). Does this sound likely or could this indicate something is slightly off?

Update:

NM, on double checking my test I found I goofed it.
The new API does produce more info in the buffers 😋

@hashseed hashseed mentioned this pull request Jun 22, 2018
@devsnek
Copy link
Member Author

devsnek commented Jun 26, 2018

landed in 4f67c6f

@devsnek devsnek closed this Jun 26, 2018
@devsnek devsnek deleted the feature/vm-snapshot-on-the-go-anytime-anywhere branch June 26, 2018 21:38
devsnek added a commit that referenced this pull request Jun 26, 2018
PR-URL: #20300
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: John-David Dalton <john.david.dalton@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Yang Guo <yangguo@chromium.org>
targos pushed a commit that referenced this pull request Jun 28, 2018
PR-URL: #20300
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: John-David Dalton <john.david.dalton@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Yang Guo <yangguo@chromium.org>
@targos targos mentioned this pull request Jul 3, 2018
targos added a commit that referenced this pull request Jul 3, 2018
Notable changes:

* build:
  * Node.js should now be about 60% faster to startup than the previous version,
    thanks to the use V8's code cache feature for core modules. [#21405](#21405)
* dns:
  * An experimental promisified version of the dns module is now available. Give
    it a try with `require('dns').promises`. [#21264](#21264)
* fs:
  * `fs.lchown` has been undeprecated now that libuv supports it. [#21498](#21498)
* lib:
  * `Atomics.wake` is being renamed to `Atomics.notify` in the ECMAScript
    specification ([reference](tc39/ecma262#1220)).
    Since Node.js now has experimental support for worker threads, we are being
    proactive and added a `notify` alias, while emitting a warning if
    `wake` is used. [#21413](#21413) [#21518](#21518)
* n-api:
  * Add API for asynchronous functions. [#17887](#17887)
* util:
  * `util.inspect` is now able to return a result instead of throwing when the
    maximum call stack size is exceeded during inspection. [#20725](#20725)
* vm:
  * Add `script.createCachedData()`. This API replaces the `produceCachedData`
    option of the `Script` constructor that is now deprecated. [#20300](#20300)
* worker:
  * Support for relative paths has been added to the `Worker` constructor. Paths
    are interpreted relative to the current working directory. [#21407](#21407)

PR-URL: #21629
targos added a commit that referenced this pull request Jul 4, 2018
Notable changes:

* dns:
  * An experimental promisified version of the dns module is now available. Give
    it a try with `require('dns').promises`. [#21264](#21264)
* fs:
  * `fs.lchown` has been undeprecated now that libuv supports it. [#21498](#21498)
* lib:
  * `Atomics.wake` is being renamed to `Atomics.notify` in the ECMAScript
    specification ([reference](tc39/ecma262#1220)).
    Since Node.js now has experimental support for worker threads, we are being
    proactive and added a `notify` alias, while emitting a warning if
    `wake` is used. [#21413](#21413) [#21518](#21518)
* n-api:
  * Add API for asynchronous functions. [#17887](#17887)
* util:
  * `util.inspect` is now able to return a result instead of throwing when the
    maximum call stack size is exceeded during inspection. [#20725](#20725)
* vm:
  * Add `script.createCachedData()`. This API replaces the `produceCachedData`
    option of the `Script` constructor that is now deprecated. [#20300](#20300)
* worker:
  * Support for relative paths has been added to the `Worker` constructor. Paths
    are interpreted relative to the current working directory. [#21407](#21407)

PR-URL: #21629
targos added a commit that referenced this pull request Jul 4, 2018
Notable changes:

* dns:
  * An experimental promisified version of the dns module is now available. Give
    it a try with `require('dns').promises`. [#21264](#21264)
* fs:
  * `fs.lchown` has been undeprecated now that libuv supports it. [#21498](#21498)
* lib:
  * `Atomics.wake` is being renamed to `Atomics.notify` in the ECMAScript
    specification ([reference](tc39/ecma262#1220)).
    Since Node.js now has experimental support for worker threads, we are being
    proactive and added a `notify` alias, while emitting a warning if
    `wake` is used. [#21413](#21413) [#21518](#21518)
* n-api:
  * Add API for asynchronous functions. [#17887](#17887)
* util:
  * `util.inspect` is now able to return a result instead of throwing when the
    maximum call stack size is exceeded during inspection. [#20725](#20725)
* vm:
  * Add `script.createCachedData()`. This API replaces the `produceCachedData`
    option of the `Script` constructor that is now deprecated. [#20300](#20300)
* worker:
  * Support for relative paths has been added to the `Worker` constructor. Paths
    are interpreted relative to the current working directory. [#21407](#21407)

PR-URL: #21629
@devsnek devsnek removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jul 18, 2018
@rauchg rauchg mentioned this pull request Nov 25, 2018
2 tasks
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++. semver-minor PRs that contain new features and should be released in the next minor version. vm Issues and PRs related to the vm subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants