doc: meeting notes from 2016-12-01 (nodejs#23)

PR-URL: nodejs/abi-stable-node#23
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Arunesh Chandra <[email protected]>
Reviewed-By: Michael Dawson <[email protected]>

meeting-notes/2016-12-01.md

@@ -0,0 +1,311 @@
+# 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.
+