Skip to content
This repository has been archived by the owner on Nov 9, 2017. It is now read-only.

Call with V8 team, #3 #156

Closed
hashseed opened this issue Jul 19, 2017 · 30 comments
Closed

Call with V8 team, #3 #156

hashseed opened this issue Jul 19, 2017 · 30 comments

Comments

@hashseed
Copy link
Member

hashseed commented Jul 19, 2017

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

Trott commented Jul 19, 2017

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

I would like to partecipate.

@mhdawson
Copy link
Member

I would like to participate

@targos
Copy link
Member

targos commented Jul 19, 2017

Me too

@hashseed
Copy link
Member Author

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

@targos
Copy link
Member

targos commented Jul 20, 2017

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

@Trott
Copy link
Member

Trott commented Jul 20, 2017

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

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

@hashseed
Copy link
Member Author

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

@Trott
Copy link
Member

Trott commented Jul 24, 2017

@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
Copy link
Member Author

hashseed commented Jul 25, 2017

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

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

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

@hashseed
Copy link
Member Author

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

Trott commented Jul 25, 2017

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

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

@hashseed
Copy link
Member Author

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

bmeck commented Jul 27, 2017 via email

@mhdawson
Copy link
Member

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

jasnell commented Jul 31, 2017

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

@jbajwa
Copy link

jbajwa commented Jul 31, 2017

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

@hashseed
Copy link
Member Author

hashseed commented Aug 1, 2017

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

@hashseed
Copy link
Member Author

hashseed commented Aug 1, 2017

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

@hashseed
Copy link
Member Author

hashseed commented Aug 1, 2017

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

fhinkel commented Aug 8, 2017

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

mcollina commented Aug 8, 2017

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

hashseed commented Aug 9, 2017

Reminder: this is in 8 minutes.

@hashseed
Copy link
Member Author

hashseed commented Aug 10, 2017

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

bmeck commented Aug 10, 2017 via email

@Trott
Copy link
Member

Trott commented Aug 13, 2017

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

@Trott Trott closed this as completed Aug 13, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants