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

test: spawn new processes in vm-cached-data #6280

Closed

Conversation

indutny
Copy link
Member

@indutny indutny commented Apr 19, 2016

Checklist
  • tests and code linting passes
  • a test and/or benchmark is included
  • the commit message follows commit guidelines
Affected core subsystem(s)

test

Description of change

V8 may start caching scripts from the first run soon. Preventively
execute scripts in another process to ensure no test failures due to
an update in the future.

See: #6258

V8 may start caching scripts from the first run soon. Preventively
execute scripts in another process to ensure no test failures due to
an update in the future.

See: nodejs#6258
@indutny indutny force-pushed the fix/use-spawn-sync-in-vm-cached-data branch from 57da6a7 to 7c07bd8 Compare April 19, 2016 15:44
@indutny
Copy link
Member Author

indutny commented Apr 19, 2016

cc @jeisinger

@indutny
Copy link
Member Author

indutny commented Apr 19, 2016

@mscdex mscdex added vm Issues and PRs related to the vm subsystem. test Issues and PRs related to the tests. labels Apr 19, 2016
@jeisinger
Copy link
Contributor

cool, LGTM

assert(!script.cachedDataProduced || script.cachedData instanceof Buffer);

if (script.cachedDataProduced)
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 return value isn't used. I think you intended to console.log or process.stdout.write it?

Copy link
Member Author

Choose a reason for hiding this comment

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

It is JS, the last statement will be printed when using -p argv.

Copy link
Member

Choose a reason for hiding this comment

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

Hm, very subtle. I guess it's not wrong but it's not very obviously correct, either. I'd use -e and explicitly print it.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ack, I agree.

@bnoordhuis
Copy link
Member

LGTM but with a strong suggestion to change the test.

@indutny
Copy link
Member Author

indutny commented Apr 20, 2016


return script.cachedData;
return new Buffer(out.stdout.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.

Buffer.from(out.stdout.toString(), 'base64')

Copy link
Member Author

Choose a reason for hiding this comment

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

Ack.

@jasnell
Copy link
Member

jasnell commented Apr 20, 2016

LGTM with a nit if CI is green


let data;
for (var i = 0; i < ${count}; i++) {
var script = new vm.Script(process.argv[1], {
Copy link
Member

Choose a reason for hiding this comment

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

Just for my understanding, process.argv[1] === undefined here, 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.

It is not, see source on line 32.

Copy link
Member Author

Choose a reason for hiding this comment

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

$ node -e 'console.log(process.argv[1])' hello
hello

Copy link
Member Author

Choose a reason for hiding this comment

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

Bet you didn't know about this 😉

Copy link
Member

Choose a reason for hiding this comment

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

Oh, I missed the third argument. Never mind.

@indutny
Copy link
Member Author

indutny commented Apr 20, 2016

Landed in e1cf634, thank you everyone!

@indutny indutny closed this Apr 20, 2016
@indutny indutny deleted the fix/use-spawn-sync-in-vm-cached-data branch April 20, 2016 16:35
indutny added a commit that referenced this pull request Apr 20, 2016
V8 may start caching scripts from the first run soon. Preventively
execute scripts in another process to ensure no test failures due to
an update in the future.

See: #6258
PR-URL: #6280
Reviewed-By: Jochen Eisinger <jochen@chromium.org>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
@jasnell
Copy link
Member

jasnell commented Apr 20, 2016

Marking it don't land in v4 simply because the future update to v8 does not apply

@MylesBorins
Copy link
Contributor

MylesBorins commented Apr 20, 2016

marking dont-land-on-v5.x for the same reason.

edit: if we want to backport we can use the commit above. I'll likely delete that branch in the next week if we do not opt for landing it

ofrobots added a commit to ofrobots/node that referenced this pull request Apr 20, 2016
V8 may cache compiled scripts, and it is not safe to assume that the
V8 flags can be changed after an isolate has been created. In this
particular case, since we are using the same script multiple times,
the test would fail if V8 cached the result of the compilation.

Ref: nodejs#6280
Fixes: nodejs#6258
ofrobots added a commit that referenced this pull request Apr 21, 2016
V8 may cache compiled scripts, and it is not safe to assume that the
V8 flags can be changed after an isolate has been created. In this
particular case, since we are using the same script multiple times,
the test would fail if V8 cached the result of the compilation.

Ref: #6280
Fixes: #6258
PR-URL: #6316
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: cjihrig - Colin Ihrig <cjihrig@gmail.com>
joelostrowski pushed a commit to joelostrowski/node that referenced this pull request Apr 25, 2016
V8 may start caching scripts from the first run soon. Preventively
execute scripts in another process to ensure no test failures due to
an update in the future.

See: nodejs#6258
PR-URL: nodejs#6280
Reviewed-By: Jochen Eisinger <jochen@chromium.org>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
joelostrowski pushed a commit to joelostrowski/node that referenced this pull request Apr 25, 2016
V8 may cache compiled scripts, and it is not safe to assume that the
V8 flags can be changed after an isolate has been created. In this
particular case, since we are using the same script multiple times,
the test would fail if V8 cached the result of the compilation.

Ref: nodejs#6280
Fixes: nodejs#6258
PR-URL: nodejs#6316
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: cjihrig - Colin Ihrig <cjihrig@gmail.com>
jasnell pushed a commit that referenced this pull request Apr 26, 2016
V8 may start caching scripts from the first run soon. Preventively
execute scripts in another process to ensure no test failures due to
an update in the future.

See: #6258
PR-URL: #6280
Reviewed-By: Jochen Eisinger <jochen@chromium.org>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
jasnell pushed a commit that referenced this pull request Apr 26, 2016
V8 may cache compiled scripts, and it is not safe to assume that the
V8 flags can be changed after an isolate has been created. In this
particular case, since we are using the same script multiple times,
the test would fail if V8 cached the result of the compilation.

Ref: #6280
Fixes: #6258
PR-URL: #6316
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: cjihrig - Colin Ihrig <cjihrig@gmail.com>
MylesBorins pushed a commit to MylesBorins/node that referenced this pull request May 11, 2016
While `let` no longer needs to run in `strict mode` in v8 5.x it throws
in v8 4. This modification will make the test-vm-cached-data work in
older version of node.

Refs: nodejs#6280

PR-URL: nodejs#6317
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
evanlucas pushed a commit that referenced this pull request May 17, 2016
While `let` no longer needs to run in `strict mode` in v8 5.x it throws
in v8 4. This modification will make the test-vm-cached-data work in
older version of node.

Refs: #6280

PR-URL: #6317
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test Issues and PRs related to the tests. vm Issues and PRs related to the vm subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants