Changes to meeting notes/2016-12-01.md. All files

meeting notes/2016-12-01.md

new file mode 100644@@ -0,0 +1,312 @@+# VM WG Summit++* Date: 2016-12-01 (Collaborators’ Summit - Austin)+* Issue: <https://github.com/nodejs/summit/issues/19>+* Notes: <https://docs.google.com/document/d/1D7-RBkuJiakADIWXOBVNyb6FNSXdoE3XIEXZ1axq97Q>+++## Attendees++* Arunesh Chandra (@aruneshchandra)+* Josh Gavant (@joshgav)+* Matteo Collina (@mcollina)+* CJ Ihrig (@cjihrig)+* Jeremiah Senkpiel (@Fishrock123)+* Rod Vagg (@rvagg)+* Taylor Woll (@boingoing)+* Hitesh Kanwathirtha (@digitalinfinity)+* James Snell (@jasnell)+* Stephen Belanger (@qard)+* Michael Dawson (@mhdawson)+* Mark Marron (@mrkmarron)+* Bert Belder (@piscisaureus)+* Myles Borins (@thealphanerd)+* JeongHoon Byun (@outsideris)+* Seth Thompson (@s3ththompson)+* Charlie Robbins (@indexzero)+* Dan Shaw (@dshaw)+++## Agenda++* Node.js Native API (NAPI)+* FFI+* VM compliance spec+* Next steps+++## Node.js Native API (NAPI)++* [Repo](https://github.com/nodejs/abi-stable-node)+* [EP](https://github.com/nodejs/node-eps/pull/20)+* [Roadmap](https://github.com/nodejs/abi-stable-node/issues/18)+++General roadmap:++1. Stable NAPI for use with native modules. NAN is currently used by many native+modules; NAPI is addressing weaknesses of NAN abstractions, specifically+leaking V8 APIs.+2. Adoption by native modules in the ecosystem.+3. Adoption by builtin modules in core. These directly use V8 APIs, will+eventually need to use NAPI.++@rvagg: TJ worked on a stable abstraction for a native ABI, but was too+difficult because of changes in V8. How confident are we that this ABI will+actually be stable for a long term, e.g. 12 months?++@mhdawson: Goal has been to prove that current ABI works with 0.10, 0.12, 4.0,+6.0, and even ChakraCore. Some adjustments were needed, but it wasn’t that+difficult to hide changes between versions. Proving that this approach works++@rvagg: What about significant future changes in V8? Do we have their buy-in?++@jasnell: Whose responsibility is it to ensure the VM APIs continue to work with+NAPI? Node’s or the VM owner’s?++@mhdawson: Depends on needs of Node and each VM.++We provide an `Environment*` pointer in each NAPI API, which gives deeper access+if necessary.++@aruneshchandra: How do we ensure buy-in from VM owners?++@rvagg: If NAPI is accepted downstream VM owners will have to participate.++@s3ththompson: The V8 team haven't yet uncovered any major issues, but we also+haven't done a full review of the proposal. Does NAPI constrain system design?+Does it constrain both/either Node or VM owners?++@jasnell: If there were to be a significant change in V8 which would affect NAPI+would V8 work together with us to address?++@s3ththompson: Hard part is defining an abstraction which provides enough wiggle+room for innovation.++@rvagg: Would be good to rephrase from “VM Neutrality,” which is somewhat+controversial, to “ABI Stable Node”, which is what is most important to users.++@mhdawson: Tested some sizeable modules, perf is within reasonable limits. Next+step is error handling. Also need more feedback from community.++API is C as we don't believe a C++ API can be as ABI-stable. However, we do want+to add some C++ sugar that would not be part of the ABI-stable API but which+would be inlined and only call the C API. A good example would be `NAN::New`.+++Completed:++* Ported all NAN examples.+* Ported leveldown and nanomsg.++Next:++* Error handling+* Perf evaluation.++At that point make available to community and seek further feedback.++@mhdawson: A challenge is that now people can use anything in V8. We will need+to constrain and support only a subset.++That means this won’t work for 100% of modules, i.e. those which do significant+work specific to V8.++@jasnell: Are there things in Node which should also be part of this API?++@mhdawson: Some libuv abstractions were already in NAN, learning from some of+those.++Buffer is another example.++@aruneshchandra: Our plan is to review the native modules in CITGM to validate+they don't use anything outside of the existing API.++@thealphanerd: There are 4-5 native modules now in CITGM, we could add more.++@indexzero provided a list: <https://github.com/nodejs/abi-stable-node/issues/22>++Could we spin up a CITGM instance for testing NAPI in particular?++@thealphanerd: Some of the modules have unusual build steps, they’ll have to be+investigated. Also CITGM can take a script instead of the default test runner.++What are the next steps on the [EP](https://github.com/nodejs/node-eps/pull/20)?++@mhdawson: Wanted to land as a draft, but still only a PR. We don’t have answers+to all the questions so haven’t been able to get consensus.++@rvagg: Need to work on landing as a Draft, which is an intended thing. Add+approval of Node-EP to next week’s CTC agenda.++@aruneshchandra: At what point can we land this in the main repo?++@rvagg: Could land as experimental.++@jasnell: Once we land as experimental will there be a way to back out? See+v8_inspector as an example.++Discussion:+* Landing as experimental gives opportunity for more feedback.+* Would be behind a configure (build-time) flag, not as discoverable as a+  runtime flag, so less risk of premature dependence.++@aruneshchandra: Should we backport to previous versions to prove usefulness?++@mhdawson: At least 2 LTS's.++And Node-ChakraCore.++First cuts for v8.x to be at end of March, be ready to bring this in behind a+flag at that time.++@rvagg: Need to ensure CTC is in the loop. Can perhaps achieve that through+review of Node-EP.++@jasnell: What do we need to achieve to consider NAPI feature-complete? All of+V8 API?++@aruneshchandra: No, not all of V8, but all that is used by native modules.++@rvagg: But modules may use a lot of those APIs (e.g. garbage collection).++@mhdawson: We’re assuming that’s a low number and we won’t address those in the+first version.++@mcollina: In order to get ecosystem on board it needs to be extremely+compelling.++@aruneshchandra: Is the ability to stay with the same module across versions+sufficiently compelling?++@mcollina: It’s nice, but the problem isn’t that hard to work around. And it+only happens when a new major version of Node is released. Lack of ecosystem+buy-in could cripple the effort.++@rvagg: Consider Electron, which often has conflicts with Node.js native+modules.++@mcollina: That could be a compelling point.++@rvagg: We think mainly about the open source ecosystem, but don’t forget the+closed users.++@aruneshchandra: People may be misled when testing because their modules based+on V8 APIs still work.++@mhdawson: We can make sure not to provide the V8 headers in the NAPI includes.+So you’d get a compile time error if depending on V8 APIs.++@jasnell: Land as experimental behind a configure (build time) flag by v8.x.+Decide before v8.x LTS whether it can come out from behind the flag.++Then decide at v10.x if it will be fully supported.++**Next steps**:++* CTC to review+  [Node-EP for abi-stable-node](https://github.com/nodejs/node-eps/pull/20).+* V8 team to review+  [NAPI implementation](https://github.com/nodejs/abi-stable-node).+* NAPI team to test against more native modules in CITGM.+* Core/CTC to land as experimental behind a build-time flag in 8.0; and to evaluate+  bringing out from flag when 8.0 goes LTS (Oct 2017).+++## FFI++@s3ththompson: V8 working on JIT-supported dynamic FFI - “Fast FFI”. Proof of+concept built which can call synchronous C functions from JS. Working on+extending to async functions. Next step is to prove in a real-world module.++Once polished V8 will publish in a branch on the V8 repo for evaluation.++It is as performant or even better than native code.++@ofrobots believes this could a solution for the needs of most native addons,+and requires less overhead.++We could push people to try to avoid C/C++ as much as possible.++@jasnell: How tightly coupled will this be with V8? How hard will it be to port+or do the same in Chakra and other VMs?++@s3ththompson: Same mechanism could be utilized in other VMs, implementation and+effects would be different.++@digitalinfinity: This would preclude running Node.js in environments where+allocating executable memory is not allowed.++Also depends on goals of native module ecosystem. If it’s to use existing C+libraries, FFI is useful. If it’s to further extend Node.js itself a native API+is more important.++@rvagg: FFI allows many runtimes to utilize same C library.++@piscisaureus: Has this been tested with significantly complex JS input?++@mrkmarron: Beware of the ease of use of FFI with legacy code, because legacy+code disrupts analysis and understanding of code.++@aruneshchandra: Do we need to choose one or the other?++@piscisareus: They shouldn’t be mutually exclusive.++@jasnell: Once things land in master, even as experimental, they are difficult+to revert.++@rvagg: Important to test against current set of modules and how they can be+covered with both/either Fast-FFI and NAPI.++@mcollina: Also need to consider migration path. Many existing modules in NAN.++@piscisareus: Could we implement NAN over NAPI to ease migration?++@mhdawson: NAN doesn’t cover all the needed abstractions, so some V8 usage is+still there. So exposing NAPI in terms of NAN won’t fix existing modules.++@piscisareus: Well then expose existing V8 APIs in terms of NAPI too!++@qard: Do we have to? Both NAN and NAPI can coexist.++@piscisareus: NAN will still be needed for those not comfortable with the NAPI C+API.++@jasnell: Would like to land them both as experimental. But would also like perf+numbers on both so we can understand and represent them both.++@jasnell: Will V8 have something usable by v8.x (April)?++@s3ththompson: Think so, need to check with Ali (@ofrobots).++@mhdawson: Would be good to have Chakra team review FFI work in V8.++**Next steps**:++* V8 to publish branch with Fast FFI implementation; Node Core and Chakra teams+  to review.++## VM Compliance Spec++Not ready to tackle this yet. First focus on ABI stable Node.js and FFI. Tackle+VM compliance later. Will need to consider ES support, diagnostic formats and+protocols support, etc.+++## Next steps++* CTC to review+  [Node-EP for abi-stable-node](https://github.com/nodejs/node-eps/pull/20).+* V8 team to review+  [NAPI implementation](https://github.com/nodejs/abi-stable-node).+* NAPI team to test against more native modules in CITGM.+* Core/CTC to land as experimental behind a build-time flag in 8.0; and to evaluate+  bringing out from flag when 8.0 goes LTS (Oct 2017).+* V8 to publish branch with Fast FFI implementation; Node Core and Chakra teams+  to review.+* API WG to hold checkpoint with CTC in late February/early March 2017, demo+  and discuss NAPI and Fast-FFI.+* Checkpoint again in mid-July, perhaps in conjunction with a community+  conference.++