Call with V8

[hashseed]

We had a few calls to sync between what was the CTC and select people from the V8 team in the past, with good outcomes.

I'd like to propose another one in the second half of January.

Some agenda items I have in mind:

• Update on GYP/GN
• GCC support in V8
• Visual Studio support in V8
• Snapshot support in Node.js
• Spectre and Meltdown
• Trace events
• Impact of async_hooks performance cliffs
• General Promise and async/await performance considerations for Node 10
• Workers in Node.js
• Memory tooling
• REPL mode for V8 parser
• V8 extras

cc @bmeurer @ajklein @ofrobots @fhinkel @mathiasbynens @natorion

Before I set up a Doodle, I'd like to get a feel for the general opinion on this.

[bmeurer]

I'd like to propose the following additions to that list:

• Impact of async_hooks performance cliffs
• General Promise and async/await performance considerations for Node 10

cc @mlippautz

[TimothyGu]

I think @bmeck would be interested in talking about a special parsing/execution mode for REPL, and perhaps about modules as well if there is anything. For that matter I’d be interested too but I’m not part of the TSC or a regular observer.

[hashseed]

I don't think anyone would mind if we invite both @bmeck and @TimothyGu

[bnoordhuis]

Status update on GYP/GN

I have an in-progress cmake branch that I should get merged but it's currently blocked on nodejs/build#1003.

[hashseed]

cmake

Even with the switch to cmake we would need a way for V8 to test against Node.js without having to maintain cmake configurations, so the GN wrapper still makes sense.

[maclover7]

Not sure if this is already documented somewhere, but I think having a more written down policy regarding support for VS2015 (is being dropped beginning in v10 IIRC?) would probably be good. IIRC, the change was related in part to things with V8

[jasnell]

Count me in. Would love to see this happen again (and becoming a regular thing).

One additional item I would add is a status update on trace event implementation, just so we can keep it on the radar.

[bmeck]

Sounds good to me.

[mhdawson]

I'd like to attend as well.

[hashseed]

Does it make sense to schedule before or after a TSC meeting? I would assume that that would be more convenient for TSC members.

[mcollina]

We do have a calendar to schedule TSC meetings when everybody can attend, can we use the same system to schedule? What do you think @Trott?

[Trott]

We do have a calendar to schedule TSC meetings when everybody can attend, can we use the same system to schedule? What do you think @Trott?

It's easy enough if we have the data. The challenge is getting everyone to enter data. Also, the TSC data is always for a Wednesday (UTC). Things get more difficult if you're talking about different days of the week.

For ad hoc meetings like this, I think Doodle might be more appropriate.

[mhdawson]

@hashseed . My experience is that its always a pain to try to schedule a time. What I'd suggest is a doodle to pick the first meeting and then make agree on a regular time slot. It's easier for people to remember and less work each time. Depending on who wants to attend though you might need to agree on a few slots and rotate.

[mhdawson]

I can see the rational of trying to piggy back onto the TSC meeting, but it runs long often enough and even if it does not people may be fatigued having it right after an hour meeting.

[hashseed]

Okay. Assuming that most are located between Europe and West Coast, I chose european evenings and west coastal mornings for the Doodle: https://doodle.com/poll/d4ubsq5t6qczcdwm

Let's agree on a suitable time before the January 19th. Thanks!

[Trott]

I filled out the Doodle, but I'm no doubt the least important person to attend, so use me as a tie-breaker only. (Turns out my availability those days is rather scarce anyway.)

[aaronleeatali]

I would like to know the future of workers in node.js. My co-workers and I have worked on this in recent moths to make workers in node.js much lighter.

[mhdawson]

@aaronleeatali see https://github.com/nodejs/worker for some past discussion/work on this front. It would be great if you could comment on existing issues or open a new one there to share your use case and experience with workers.

[yunong]

I would be interested in attending.

[hashseed]

It's not quite January 19th yet, but I'd like to propose the final choice, based on the Doodle outcome:

January 31st, 7:15 PM Central European Time, 10:15 AM Pacific Time.

[TimothyGu]

Seems like I'll be one of the only two people to miss the meeting... oh well. I do have a class during that time but I'll see if I can miss it. That's my long-winded way of saying "sounds good to me." and I have a midterm for that class the day after the call, so I probably won't be there. Have a nice meeting then.

[aaronleeatali]

@mhdawson Thanks.
I am reading this and I hope our work can makes a positive contribution.
We have implemented worker in node.js which is relatively light-weight.
The design document and the performance data will be published after we finish our job.
We would be glad to receive feedback then.

[hashseed]

@TimothyGu sorry that the date doesn't suit you. I will take meticulous notes.

[hashseed]

Invitation has been sent. Let me know if I should extend it to more folks.

[mhdawson]

@hashseed depending on how open it is, it would be great if @mmallick-ca, @jBarz could be invited. They work with me keeping our V8 ports up to date for s390 and PowerPC

[hashseed]

@mhdawson no objections here. I extended the invitation to both.

[jasnell]

@hashseed ... can you please include me on that as well? (I haven't seen an invitation come through so just want to make sure)

[hashseed]

I thought I already did. In any case I removed and readded you from the calendar event.

[fhinkel]

Should we plan on streaming/recording this on YouTube?

[dshaw]

@fhinkel Recording this meeting would be great. I would definitely be interested in viewing this, but have been resisting piling on just to observe. Thank you.

[hashseed]

I have no idea how to stream to YouTube. Would anyone be willing to set it up?

[mhdawson]

I created a youtube event. The main limitation is that I think we can only have ~10 people (although I think the limit might be 15 for our account). https://www.youtube.com/watch?v=Cg1jWTPAIDU is the link for those who want to watch. I'll post the link for participants a few minutes before the meeting (Same can be done by any "manager" of the Node.js youtube account)

[TimothyGu]

Even though I probably will not be there at the meeting, if possible I'd like to add to the agenda to talk about hooks in v8::Module that would allow more efficient deprecation of module exports. Much of the discussion began in nodejs/node#18131, but I'll summarize it below.

Currently, Node.js uses self-hosted CJS files for implementation of core modules. To deprecate an export, we have two ways:

1. If the export is a function, we emit a warning to stderr saying that the function is deprecated and should no longer be used when the function is first called.
2. If the export is a regular property, we emit a warning when the property is first accessed through a getter function on the module.

While option 1 still works with ES Modules, option 2 does not, since ES Modules' exports are not an object users can manipulate. But even with option 1, the current situation is not ideal, as an exported function may not always be called during development, thus preventing a developer from seeing the deprecation warning.

Of course, we can just change properties to getter/setter function pairs that are each exported. However, with ESM, ideally we would have a chance to introspect a particular ES Module, and to emit a warning every time a deprecated binding gets imported. Better deprecation support is in fact recognized by some TSC members as an exit criterion of the ES Modules feature in Node.js. With the static/declarative nature of ESM syntax, this would be technically possible. Not only would this solve the problem of deprecating properties, but also provide more accurate reports of deprecated functions to users.

Some open questions remain about what we should do with import * and export *, however.

[mhdawson]

I accidentally used the meeting I had set up during the last benchmarking meeting. So new hangout. Link for those who just want to watch https://www.youtube.com/watch?v=4Fz6Tz9kb_s. Will post link for participants a few mins before meeting start.s

[mhdawson]

Link for participants https://hangouts.google.com/hangouts/_/ytl/emObhwJJLj7HA6hCi7-oPVFpXGNfwukePeqM4RIQVEE=?eid=100598160817214911030

[bmeurer]

Would it be possible to reorder the agenda items to have these first?

• Impact of async_hooks performance cliffs
• General Promise and async/await performance considerations for Node 10
• Workers in Node.js
• Memory tooling
• V8 extras

[ofrobots]

video call is full 😿

[cjihrig]

yes, what @ofrobots said

[jasnell]

Ditto. Unable to join. Can we please pick something other than hangouts with higher capacity

[mhdawson]

Going to setup a zoom instead

[mhdawson]

https://zoom.us/s/157133358

[mcollina]

https://zoom.us/j/157133358

[devsnek]

is this no longer going to be streamed?

[Fishrock123]

We are live on https://www.youtube.com/c/nodejs-foundation/live

[Fishrock123]

The video recording is still processing but I'll post here when it's done.

[jasnell]

Good thing you were recording because it looks like the zoom recording wasn't turned on :-)

[Fishrock123]

Youtube recording: https://youtu.be/a6YtLIaqMqs (Our stream settings are set to do archiving automatically.)

[Fishrock123]

@hashseed Think you could get us a link again to the clang presentation slides? I'd like to annotate the recording there.

Unfortunately I was not set up to record the actual video (and didn't really even think about it due to how our regular meetings are). That discussion starts at https://youtu.be/a6YtLIaqMqs?t=47m4s for like 20mins.

[hashseed]

@Fishrock123 here's the clang presentation.

[hashseed]

I created a summary.