This repository has been archived by the owner on Oct 7, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 12
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #8 from nodejs/vm-summit-4-notes
meeting notes for VM Summit #4
- Loading branch information
Showing
1 changed file
with
101 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,101 @@ | ||
# VM Summit #4 Meeting Notes | ||
|
||
Thank you NodeSource for hosting the VM Summit. | ||
|
||
* FFI Update – Ali | ||
* No progress since last time, resource issues | ||
* Still interest, makes sense for other reasons as well for V8 team | ||
* FFI- vm | ||
* A tool for creating native modules that primarily bind C libraries to JS dynamically generates bindings to C functions. Efficient for wrapping existing c functions | ||
* Complementary to N-API which is needed for other use cases. | ||
* The big impetus for NAPI was native module developers, so FFI is important to us because it helps them | ||
* Does move to turbo fan/ignition affect FFI as it used to be completely jitted but not its interpreted to start. Ali - no, jit would still be used to generate the glue. | ||
* Dshaw: suggesting that maybe a broader work group (google + outside google) could help make progress. | ||
* Discussion around starting by defining a spec, that would allow a generator to N-API, then for migration when direct vm support is available. | ||
* Mozilla has ‘ctypes’ which is not a recommended example. | ||
* What is the primary V8 use case for this? | ||
* Node | ||
* WebAssembly could benefit from this, but it is not immediately a priority for them | ||
* Next steps | ||
* Setup repo … done! https://github.com/nodejs/ffi (initial nodejs/ffi team created) | ||
* Setup regular meeting | ||
* Collect use cases - https://github.com/nodejs/ffi/issues/1 | ||
* N-API Update – Michael & Arunesh | ||
* Adoption efforts | ||
* https://github.com/nodejs/abi-stable-node/issues/246 | ||
* https://github.com/nodejs/abi-stable-node/issues/245 | ||
* Awareness | ||
* Node Summit | ||
* Node Interactive | ||
* NodeConfEU | ||
* Exit experimental status | ||
* By end of August? | ||
* Remove enabling flag? (barrier to use) Consensus in room to remove the flag.. Should get a PR soon for this | ||
* No process warning either? | ||
* What is the experimental exit criteria? | ||
* Need tracking issue with clarifications of criteria | ||
* Write up on the prebuilt toolchain with n-api | ||
* Multiple implementations | ||
* 2 or more VM implementations | ||
* 2 or more modules that are NPM installable with pre-builds and all unit tests passing | ||
* Both modules used in real world use cases on at least one VM | ||
* A PoC that shows this working that exercising all the code paths | ||
* Enable N-API for async_hooks (async_hooks expert needed) | ||
* There is a subset of async_hooks that napi and async_hooks needs to agree to for stability | ||
* We don’t want to tie this to NAPI’s non-experimental status, this is not an exit criteria for NAPI | ||
* We want to continue working on this, but not going to pull it into NAPI until its stable | ||
* Next steps | ||
* Refine this criteria in a GH issue | ||
* Opened https://github.com/nodejs/node/issues/14532 | ||
* Find two module owners and get buy in | ||
* Matteo - https://github.com/mcollina/native-hdr-histogram will do an experimental release | ||
* Work in issue #13254 to Identify the intersection of NAPI and async_hooks stability, which parts of the async_hooks are important to NAPI’s stability | ||
* Take up a case study for Migrating NAN modules to N-API | ||
* NAN Evolution | ||
|
||
* JerryScript use of N-API – Gabriel | ||
* https://docs.google.com/presentation/d/1fE8g-r0Y7Xzin3LRn1fV6YBCFS5IcySjyRcARMSSadE/edit#slide=id.p3 | ||
|
||
* VM Diversity | ||
* Experiment update: N-API port of Core modules - Jason | ||
* Experiment conducted porting node_file.cc to N-API successful but there's a lot more to do. | ||
* Need to expand N-API V8 API coverage to account for core uses. Should those new N-API bits be public? | ||
* Need to do performance testing. This is difficult because some shimming is required. Won't have a complete picture of performance until the full migration is done | ||
* Next: convert something more extensive, like StreamBase and sockets. | ||
* Goal: eventually, Node.js core itself should only be using N-API for it's own interactions with the VM | ||
* Compliance suite – Myles | ||
* We did not get to this in detail, tho it was discussed briefly. Will be picking this item up on the next VM summit. | ||
|
||
## Other topics – if there is time and interest | ||
|
||
We did not get to these topics... | ||
|
||
* Inspector protocol | ||
* Improving problem determination – debugging / tracing | ||
* iOS and mobile scenario for Node | ||
* Matteo’s research on Turbofan | ||
* Workers (https://github.com/nodejs/worker) | ||
|
||
----- | ||
|
||
# Attendees: | ||
|
||
* Ali Sheikh (Google) | ||
* Anil Kumar (Intel) | ||
* Arunesh Chandra (Microsoft) | ||
* Boaz Sender (Bocoup) | ||
* Dan Shaw | ||
* Gabriel Schulhof (Intel) | ||
* Hitesh Kanwathirtha (Microsoft) | ||
* James Snell (nearForm) | ||
* Jason Ginchereau (Microsoft) | ||
* Joe Doyle (NodeSource) | ||
* Justin Beckwith (Google) | ||
* Mark Marron (Microsoft) | ||
* Matt Hargett | ||
* Matteo Collina (nearForm) | ||
* Michael Dawson (IBM) | ||
* Refael Ackermann | ||
* Rod Vagg (NodeSource) | ||
* Shu-yu (Mozilla) | ||
* Thomas Nattestad (Google) |