From 040e07738a671093b6d529815f4fc5f72ba66f3d Mon Sep 17 00:00:00 2001 From: Josh Gavant Date: Thu, 1 Dec 2016 20:09:25 -0800 Subject: [PATCH] doc: meeting notes from 2016-12-01 PR-URL: https://github.com/nodejs/abi-stable-node/pull/23 Reviewed-By: James M Snell Reviewed-By: Arunesh Chandra Reviewed-By: Michael Dawson --- meeting-notes/2016-12-01.md | 311 ++++++++++++++++++++++++++++++++++++ 1 file changed, 311 insertions(+) create mode 100644 meeting-notes/2016-12-01.md diff --git a/meeting-notes/2016-12-01.md b/meeting-notes/2016-12-01.md new file mode 100644 index 0000000000..ffec070a18 --- /dev/null +++ b/meeting-notes/2016-12-01.md @@ -0,0 +1,311 @@ +# VM WG Summit + +* Date: 2016-12-01 (Collaborators’ Summit - Austin) +* Issue: +* Notes: + + +## 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: + +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. +