Call with V8 team, #3

[hashseed]

We had two previous meetings, both well received from what I can tell.

There were some opportunities to talk to each other at JSConf.eu, and I assume that we will have some more in October at Node Interactive and the following collaborator summit.

Until then, I think it makes sense to set up a meeting to sync up before Node Interactive. Some topics that I have in mind:

• Progress of ES6 modules.
• Custom startup snapshot. @bmeck seems to have explored this a bit. Does it make sense to invest time in this, on both ends?
• Let's recap the hash flooding issue to make sure we can make the process of handling security issues smoother.
• Is V8 6.1 on the table for Node 8?
• Performance discussions.
• Node.js beta release with a less stable V8?

The previous two meetings were at 10am PST and 9pm PST respectively, both on Wednesdays. Is there any preference for a different choice of time?

@bmeurer @psmarshall @fhinkel @ajklein

[Trott]

@hashseed We have a private spreadsheet containing information about availability of CTC members at different times. If you happen to know certain people on the Node.js side that you want to particularly try to have at the meeting, you can send me their names (email in my GitHub profile). I can give you a few times that the particular group of people you are interested in are likely to be available on a UTC Wednesday.

[mcollina]

I would like to partecipate.

[mhdawson]

I would like to participate

[targos]

Me too

[hashseed]

I'd also like to talk with someone who is familiar with the progress wrt modules. Maybe @jasnell?

[targos]

there is now a PR to introduce modules: https://github.com/nodejs/node/pull/14369

[Trott]

I'd also like to talk with someone who is familiar with the progress wrt modules. Maybe @jasnell?

Maybe @bmeck? He's not a CTC member, but he's a frequent guest/observer at the CTC meetings specifically because of modules. Especially if the meeting is happening soon, he may not be available though, in which case perhaps he can suggest someone else.

[hashseed]

I was thinking some time early August, so people can plan two weeks ahead.

[hashseed]

@Trott I'd like to take up on your offer. Can you suggest a good time for everyone who want to participate?

[Trott]

@hashseed UTC 17:00 18:00 20:00 seem to be the best times (at least on Wednesdays, but probably generalizable to Monday through Friday) for targos + mhdawson + mcollina + jasnell.

[hashseed]

I set up a Doodle: http://doodle.com/poll/h34rqhwk6q89vmx9

I chose August 8th to 10th (Tuesday to Thursday) either at UTC 17:00, 18:00 or 22:00. UTC 20:00 turns out to be very inconvenient for the V8 team when people are hurrying home and/or getting dinner.

Edit: link to new Doodle.

[hashseed]

I actually made a mistake translating the time zone. I thought UTC 17:00 would be CEST 15:00 when it's actually CEST 19:00.

Please tell me if I should create a new Doodle for this!

[bnoordhuis]

Hah, I wondered about that. I'd say a new doodle is better.

[hashseed]

Here's the new Doodle: http://doodle.com/poll/h34rqhwk6q89vmx9

I kept the 3pm CEST option.

@bnoordhuis @bmeck @targos please enter your preferences again, sorry!

[Trott]

I'm interested in attending but I think my participation is far less crucial than the other folks who have chimed in, so I'll refrain from filing out the Doodle, but if the time that ultimately is selected works for me, I'd love to attend. I'll even volunteer to take minutes if you want.

[hashseed]

@MylesBorins I think you used the stale link. The correct one is: https://beta.doodle.com/poll/h34rqhwk6q89vmx9

[hashseed]

Looks like the winning options so far are

• August 8th UTC 1pm
• August 9th UTC 6pm
• August 10th UTC 1pm

@ajklein @bmeck wdyt if we schedule it on August 10th UTC 1pm for the Node.js CTC call with V8, and a second, smaller meeting on the same day UTC 8pm to discuss modules? I can join both and will take meeting notes (unless Trott does it :).

[bmeck]

I can be at any/all meetings on the 9th and 10th, I cannot attend on the 8th.

On Wed, Jul 26, 2017 at 10:33 PM, Yang Guo notifications@github.com wrote:

Looks like the winning options so far are

• August 8th UTC 1pm
• August 9th UTC 6pm
• August 10th UTC 1pm

@ajklein https://github.com/ajklein @bmeck https://github.com/bmeck wdyt if we schedule it on August 10th UTC 1pm for the Node.js CTC call with V8, and a second, smaller meeting on the same day UTC 8pm to discuss modules? I can join both and will take meeting notes (unless Trott does it :).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nodejs/CTC/issues/156#issuecomment-318263196, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOUoximQo71cTTASRpafoA2XcXYryZuks5sSCE1gaJpZM4OcQkW .

[mhdawson]

Unfortunately I'm away on holiday the week of the 8th so I won't be able to make it. @jbajwa can you make it ?

[jasnell]

The 9th and 10th work well for me. The 8th is completely unavailable.

[jbajwa]

I can also attend on the 9th or 10th. I've updated the doodle poll accordingly.

[hashseed]

Looks like August 9th UTC 6pm is winning. Let's meet at that time!

[hashseed]

Link in case you did not get the calendar invite https://staging.talkgadget.google.com/hangouts/_/google.com/ctc-v8

[hashseed]

Aside from the agenda items I mentioned above, is there anything else someone wants to talk about? For people who can't join, you can also bring up your topics for discussion. I will take notes and publish them.

@bmeurer

[fhinkel]

Looks like August 9th UTC 6pm is winning. Let's meet at that time!

@williamkapke do you want to add this to the official Node calendar? Thanks.

[mcollina]

I will not be able to join :(.

Regarding performance, I would like to start a discussion with the V8 team on how to improve certain areas of Node.js (process.nextTick, EventEmitter.emit, setImmediate, OutgoingMessage.setHeader and others) with their support. There are some very hot functions that were implemented in CrankshaftScript that might be improved, or migrated to some new syntax that can be greatly optimized by V8 itself, e.g. the rest and spread operator.

[hashseed]

Reminder: this is in 8 minutes.

[hashseed]

Meeting notes. I might have gotten some content or names wrong. Correct me if I did.

Attendants: @addaleax @ajklein @bmeck @bmeurer @cjihrig @fhinkel @hashseed @jasnell @matthewloring @MylesBorins @natorion @ofrobots @psmarshall @targos @Trott (I probably forgot a few people, please correct me here!)

Security process

@hashseed: Given the experience with the hash flooding issue and the subsequent security release, is there anything in the process that could have been improved? @jasnell: Not sure. Severity of this particular issue is debatable. @MylesBorins: Google Cloud Platform team already has access to Node.js security repository. This security release has been delayed a few times due to bad timing. @hashseed: The fix for this had to be floated on Node.js because it does not fit Chrome's threat model and we were not able to merge it back upstream.

Progress of ES6 modules

@bmeck: PR is pending, waiting for dynamic imports to be implemented inV8. Otherwise on track, going to introduce a command line flag in Node 9 and hoping to continuously making progress on Node 9. @ajklein: Chrome plans a staged roll out without dynamic imports at first. Is Node.js blocked by this? @bmeck: No. @ajklein: Are import metadata required in Node? @bmeck: For larger things, yes. @ajklein: We are already prioritizing dynamic import, also wrt V8 API. Is the existing API good enough? @bmeck: So far yes, aside from dynamic imports. @MylesBorins: What about compatibility between browser and Node.js? MIME types for browser, but what for Node.js? .mjs file extension to distinguish ESM from CJS? What about interop? @bmeck: .json files are also affected. NPM packages don't support ESM anyways, might be solvable by pragma. @bmeurer: We expect modules in browsers to be bundled even with ESM due to performance concerns. @ajklein: No interop between ESM and CJS would be simplest. @MylesBorins: I.e. import only works for ESM and require only works for CJS. Ideally import acts exactly the same as in the browser. @bmeck: This discussion has been brought up last year already. @ajklein: But without any conclusion. @bmeurer: Node.js is already different than the browser in many places.

Custom startup snapshot

@hashseed: We are extending the feature set of V8's startup snapshot, e.g. to support TypedArrays and ArrayBuffers. Is there interest? @bmeck: I have explored this a bit. My employer has a use case for this. But currently on hold due to work on ES6 modules. Revisiting this by EOY. TypedArray support is very important. Node.js may use external off-heap backing stores though. @hashseed: The use cases I envision is to be able to start up Node.js faster preloaded with tools such as TypeScript compiler or Babel. @bmeck: More thinking of faster startup with preloaded applications.

Should Node 8 upgrade to V8 6.1 eventually?

@hashseed: V8 6.1 is noticeably better than 6.0 since we fixed a few performance issues with TF+I. It would be great if we can include these fixes in Node 8. @bmeurer: V8 6.1 fixes a few regressions for Node.js micro-benchmarks. @targos: Generally no objection, if V8 can ensure ABI compatibility. @hashseed: We prepared for that. Some fixes have been landed upstream to ensure ABI compatiblity, some changes have to be floated. For example some typedef renamings, and In particular v8::Object::ForceSet has been removed in 6.1 and would need to be restored. @targos: Maybe not if ForceSet has already been marked deprecated. @addaleax Probably should restore ForceSet. @natorion: V8 6.1 goes stable early September, so it should be possible to upgrade to 6.1 before Node 8 goes LTS.

Should the master branch be updated to V8 beta version?

@ofrobots: Master branch with beta V8 would be very welcome. @targos: What's the difference to the Canary build? @ofrobots: Canary is not the master branch. @natorion: V8 beta has a lower bar for merging patches to upstream. It's hard to convince Chromium release managers to accept a merge to V8 stable. V8 beta also has a longer lifetime. @ofrobots: Using V8 beta on master would lessen the workload of merging fixes. @targos: Would that put users at increased risk of breakages? @bmeurer: V8 beta is a lot more stable than you might think. It has already survived Chrome Canary and Dev channels. Even better if you wait for one week of Chrome Beta channel coverage.

Should code patterns tailored for Crankshaft in Node.js be replaced by idiomatic JS?

@bmeurer: TF+I has been forced to support weird code patterns tailored for Crankshaft. @cjihrig - tweet @bmeurer: Some assumptions were even outdated in Crankshaft. @jasnell: This would have to be decided case by case. Usually it's hard to argue for a change if it means churn without very convincing impact. @bmeurer: We can try. Unfortunately there are no good benchmarks. This has bitten us when launching I+TF. Browsers on the other hand have many performance tests. Node.js has wide uses with very different workloads, making things even harder. @hashseed: Yes, we could start with small steps. @bmeurer: @mcollina's blog post is great btw.

FFI

@hashseed: Is there demand for this? @jasnell: FFI is definitely great to have. @ofrobots: VM summit #4 discussed how this relates to NAPI. @bmeurer: How about automatically generating C++ wrappers from IDL instead? @ofrobots: That would be static and not as convenient.

Post-mortem diagnostics.

@hashseed: Is there demand for this? @cjihrig: There is node-report. @jasnell: How does this differ from llnode? @hashseed: This would be higher-level. I.e. we would capture a snapshot that can be explored with Chrome DevTools, e.g. inspecting local variables or even evaluating simple expressions. @jasnell: Let's file a bug and collect opinions.

[bmeck]

@ajklein https://github.com/ajklein: But without any conclusion.

I think this is incorrect. As I stated, this was voted on last year. There was a conclusion that interop is needed.

On Thu, Aug 10, 2017 at 8:17 AM, Yang Guo notifications@github.com wrote:

Meeting notes. I might have gotten some content or speakers wrong. Correct me if I did.

Attendants: @addaleax https://github.com/addaleax @ajklein https://github.com/ajklein @bmeck https://github.com/bmeck @bmeurer https://github.com/bmeurer @cjihrig https://github.com/cjihrig @fhinkel https://github.com/fhinkel @hashseed https://github.com/hashseed @jasnell https://github.com/jasnell @MylesBorins https://github.com/mylesborins @natorion https://github.com/natorion @ofrobots https://github.com/ofrobots @psmarshall https://github.com/psmarshall @targos https://github.com/targos @Trott https://github.com/trott (I probably forgot a few people, please correct me here!) Security process

@hashseed https://github.com/hashseed: Given the experience with the hash flooding issue and the subsequent security release https://nodejs.org/en/blog/vulnerability/july-2017-security-releases/#header-node-js-specific-security-flaws, is there anything in the process that could have been improved? @jasnell https://github.com/jasnell: Not sure. Severity of this particular issue is debatable. @MylesBorins https://github.com/mylesborins: Google Cloud Platform team already has access to Node.js security repository. This security release has been delayed a few times due to bad timing. @hashseed https://github.com/hashseed: The fix https://github.com/nodejs/node/commit/2ae2874ae7dfec2c55b5d390d25b6eed9932f78d for this had to be floated on Node.js because it does not fit Chrome's threat model and we were not able to merge it back upstream. Progress of ES6 modules

@bmeck https://github.com/bmeck: PR is pending, waiting for dynamic imports to be implemented inV8. Otherwise on track, going to introduce a command line flag in Node 9 and hoping to continuously making progress on Node 9. @ajklein https://github.com/ajklein: Chrome plans a staged roll out without dynamic imports at first. Is Node.js blocked by this? @bmeck https://github.com/bmeck: No. @ajklein https://github.com/ajklein: Are import metadata required in Node? @bmeck https://github.com/bmeck: For larger things, yes. @ajklein https://github.com/ajklein: We are already prioritizing dynamic import, also wrt V8 API. Is the existing API good enough? @bmeck https://github.com/bmeck: So far yes, aside from dynamic imports. @MylesBorins https://github.com/mylesborins: What about compatibility between browser and Node.js? MIME types for browser, but what for Node.js? .mjs file extension to distinguish ESM from CJS? What about interop? @bmeck https://github.com/bmeck: .json files are also affected. NPM packages don't support ESM anyways, might be solvable by pragma. @bmeurer https://github.com/bmeurer: We expect modules in browsers to be bundled even with ESM due to performance concerns. @ajklein https://github.com/ajklein: No interop between ESM and CJS would be simplest. @MylesBorins https://github.com/mylesborins: I.e. import only works for ESM and require only works for CJS. Ideally import acts exactly the same as in the browser. @bmeck https://github.com/bmeck: This discussion has been brought up last year already. @ajklein https://github.com/ajklein: But without any conclusion. @bmeurer https://github.com/bmeurer: Node.js is already different than the browser in many places. Custom startup snapshot

@hashseed https://github.com/hashseed: We are extending the feature set of V8's startup snapshot, e.g. to support TypedArrays and ArrayBuffers. Is there interest? @bmeck https://github.com/bmeck: I have explored https://github.com/nodejs/node/issues/13877 this a bit. My employer has a use case for this. But currently on hold due to work on ES6 modules. Revisiting this by EOY. TypedArray support is very important. Node.js may use external off-heap backing stores though. @hashseed https://github.com/hashseed: The use cases I envision is to be able to start up Node.js faster preloaded with tools such as TypeScript compiler or Babel. @bmeck https://github.com/bmeck: More thinking of faster startup with preloaded applications. Should Node 8 upgrade to V8 6.1 eventually?

@hashseed https://github.com/hashseed: V8 6.1 is noticeably better than 6.0 since we fixed a few performance issues with TF+I. It would be great if we can include these fixes in Node 8. @bmeurer https://github.com/bmeurer: V8 6.1 fixes a few regressions for Node.js micro-benchmarks. @targos https://github.com/targos: Generally no objection, if V8 can ensure ABI compatibility. @hashseed https://github.com/hashseed: We prepared https://github.com/nodejs/node/issues/14220 for that. Some fixes have been landed upstream to ensure ABI compatiblity, some changes have to be floated. For example some typedef renamings, and In particular v8::Object::ForceSet has been removed in 6.1 and would need to be restored. @targos https://github.com/targos: Maybe not if ForceSet has already been marked deprecated. @addaleax https://github.com/addaleax Probably should restore ForceSet. @natorion https://github.com/natorion: V8 6.1 goes stable early September, so it should be possible to upgrade to 6.1 before Node 8 goes LTS. Should the master branch be updated to V8 beta version?

@ofrobots https://github.com/ofrobots: Master branch with beta V8 would be very welcome. @targos https://github.com/targos: What's the difference to the Canary build? @ofrobots https://github.com/ofrobots: Canary is not the master branch. @natorion https://github.com/natorion: V8 beta has a lower bar for merging patches to upstream. It's hard to convince Chromium release managers to accept a merge to V8 stable. V8 beta also has a longer lifetime. @ofrobots https://github.com/ofrobots: Using V8 beta on master would lessen the workload of merging fixes. @targos https://github.com/targos: Would that put users at increased risk of breakages? @bmeurer https://github.com/bmeurer: V8 beta is a lot more stable than you might think. It has already survived Chrome Canary and Dev channels. Even better if you wait for one week of Chrome Beta channel coverage. Should code patterns tailored for Crankshaft in Node.js be replaced by idiomatic JS?

@bmeurer https://github.com/bmeurer: TF+I has been forced to support weird code patterns tailored for Crankshaft. @cjihrig https://github.com/cjihrig - tweet https://twitter.com/cjihrig/status/895055654297239553 @bmeurer https://github.com/bmeurer: Some assumptions were even outdated in Crankshaft. @jasnell https://github.com/jasnell: This would have to be decided case by case. Usually it's hard to argue for a change if it means churn without very convincing impact. @bmeurer https://github.com/bmeurer: We can try. Unfortunately there are no good benchmarks. This has bitten us when launching I+TF. Browsers on the other hand have many performance tests. Node.js has wide uses with very different workloads, making things even harder. @hashseed https://github.com/hashseed: Yes, we could start with small steps. @bmeurer https://github.com/bmeurer: @mcollina https://github.com/mcollina's blog post is great btw. FFI

@hashseed https://github.com/hashseed: Is there demand for this? @jasnell https://github.com/jasnell: definitely some demand for this. @ofrobots https://github.com/ofrobots: VM summit #4 https://github.com/nodejs/CTC/issues/4 discussed how this relates to NAPI. @bmeurer https://github.com/bmeurer: How about automatically generating C++ wrappers from IDL instead? @ofrobots https://github.com/ofrobots: That would be static and not as convenient. Post-mortem diagnostics.

@hashseed https://github.com/hashseed: Is there demand for this? @cjihrig https://github.com/cjihrig: There is node-report. @jasnell https://github.com/jasnell: How does this differ from llnode? @hashseed https://github.com/hashseed: This would be higher-level. I.e. we would capture a snapshot that can be explored with Chrome DevTools, e.g. inspecting local variables or even evaluating simple expressions. @jasnell https://github.com/jasnell: Let's file a bug and collect opinions.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nodejs/CTC/issues/156#issuecomment-321548010, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOUo_ljK75E772T_GgpTos7NNZeuOX4ks5sWwL4gaJpZM4OcQkW .

[Trott]

I imagine that since this meeting happened, this issue can be closed. If I'm wrong about that, please comment or re-open. Thanks!