Call with V8 team, #3 #156
Comments
|
@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 |
|
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 |
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 I'd like to take up on your offer. Can you suggest a good time for everyone who want to participate? |
|
@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. |
|
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. |
|
@MylesBorins I think you used the stale link. The correct one is: https://beta.doodle.com/poll/h34rqhwk6q89vmx9 |
|
Looks like the winning options so far are
@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>
.
|
|
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 |
|
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. |
@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 ( |
|
Reminder: this is in 8 minutes. |
|
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? 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. 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? 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. Should the master branch be updated to V8 beta version?@ofrobots: Master branch with beta V8 would be very welcome. 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. FFI@hashseed: Is there demand for this? Post-mortem diagnostics.@hashseed: Is there demand for this? |
|
@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! |
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:
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
The text was updated successfully, but these errors were encountered: