Call with V8 team, #3

@bmeck

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

@hashseed

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

I would like to partecipate.

I would like to participate

Me too

@jasnell

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

there is now a PR to introduce modules: nodejs/node#14369

@jasnell

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.

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

@Trott

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

@hashseed

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

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.

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!

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

@bnoordhuis

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!

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.

@ajklein

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

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 ***@***.***> 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 <#156 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOUoximQo71cTTASRpafoA2XcXYryZuks5sSCE1gaJpZM4OcQkW> .

@jbajwa

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 ?

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

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

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

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

@bmeurer

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

@williamkapke

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.

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.

Reminder: this is in 8 minutes.

@addaleax

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.

@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 ***@***.***> 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 <nodejs/node@2ae2874> 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 <nodejs/node#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 <nodejs/node#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 <#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 <#156 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOUo_ljK75E772T_GgpTos7NNZeuOX4ks5sWwL4gaJpZM4OcQkW> .

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

Navigation Menu

Repository navigation

Call with V8 team, #3 #156

1 remaining item

Security process

Progress of ES6 modules

Custom startup snapshot

Should Node 8 upgrade to V8 6.1 eventually?

Should the master branch be updated to V8 beta version?

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

FFI

Post-mortem diagnostics.

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Call with V8 team, #3 #156

Description

Activity

Trott commented on Jul 19, 2017

mcollina commented on Jul 19, 2017

mhdawson commented on Jul 19, 2017

targos commented on Jul 19, 2017

hashseed commented on Jul 20, 2017

targos commented on Jul 20, 2017

Trott commented on Jul 20, 2017

hashseed commented on Jul 20, 2017

hashseed commented on Jul 24, 2017

Trott commented on Jul 24, 2017

hashseed commented on Jul 25, 2017

hashseed commented on Jul 25, 2017

bnoordhuis commented on Jul 25, 2017

hashseed commented on Jul 25, 2017

Trott commented on Jul 25, 2017

1 remaining item

hashseed commented on Jul 27, 2017

bmeck commented on Jul 27, 2017

mhdawson commented on Jul 29, 2017

jasnell commented on Jul 31, 2017

jbajwa commented on Jul 31, 2017

hashseed commented on Aug 1, 2017

hashseed commented on Aug 1, 2017

hashseed commented on Aug 1, 2017

fhinkel commented on Aug 8, 2017

mcollina commented on Aug 8, 2017

hashseed commented on Aug 9, 2017

hashseed commented on Aug 10, 2017

Security process

Progress of ES6 modules

Custom startup snapshot

Should Node 8 upgrade to V8 6.1 eventually?

Should the master branch be updated to V8 beta version?

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

FFI

Post-mortem diagnostics.

bmeck commented on Aug 10, 2017

Trott commented on Aug 13, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions