We're now starting the ball rolling on the WasmGC Origin Trial, so we expect the 6 milestone approval to cover M111 - M116.
On Fri, Feb 10, 2023 at 6:56 AM Mike Taylor <[email protected]> wrote: > LGTM to experiment w/ an OT for 6 milestones. > > On 2/9/23 1:57 PM, Adam Klein wrote: > > On Thu, Feb 9, 2023 at 1:32 AM Yoav Weiss <[email protected]> wrote: > >> This is super exciting!! Thanks for working on this :) >> >> +Jason Robbins <[email protected]> - FYI, this intent also didn't show >> up in our tooling.. >> > > This may be my fault, the intent wasn't taken *directly* from > ChromeStatus but generated there, copied to a doc for further editing, and > then sent. > > >> On Wed, Feb 8, 2023 at 1:01 AM Adam Klein <[email protected]> wrote: >> >>> Contact emails >>> >>> [email protected], [email protected] >>> >>> Explainer >>> >>> https://github.com/WebAssembly/gc/blob/main/proposals/gc/Overview.md >>> >>> Specification >>> >>> MVP GC spec: >>> https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP.md >>> >>> MVP JS API: >>> https://docs.google.com/document/d/17hCQXOyeSgogpJ0I0wir4LRmdvu4l7Oca6e1NkbVN8M/edit >>> >>> stringref: >>> https://github.com/WebAssembly/stringref/blob/main/proposals/stringref/Overview.md >>> >>> Design docs >>> >>> >>> https://docs.google.com/document/d/1DklC3qVuOdLHSXB5UXghM_syCh-4cMinQ50ICiXnK3Q/edit >>> >>> Summary >>> >>> The GC proposal adds efficient support for high-level managed languages >>> to WebAssembly, via struct and array types that enable language compilers >>> targeting Wasm to integrate with a garbage collector in the host VM. >>> >>> The separate stringref proposal allows Wasm to efficiently create, >>> manipulate, and pass host-provided strings to & from the host. In browsers, >>> these are JavaScript strings. Though it’s not part of the GC proposal, for >>> convenience of language partners we want to include it as part of this >>> Origin Trial. Shipment readiness of stringrefs will be evaluated separately >>> in the future. >>> >>> Blink component >>> >>> Blink>JavaScript>WebAssembly >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly> >>> >>> Search tags >>> >>> wasm <https://chromestatus.com/features#tags:wasm>, webassembly >>> <https://chromestatus.com/features#tags:webassembly>, gc >>> <https://chromestatus.com/features#tags:gc>, managed objects >>> <https://chromestatus.com/features#tags:managed%20objects>, wasmgc >>> <https://chromestatus.com/features#tags:wasmgc> >>> >>> TAG review >>> >>> https://github.com/w3ctag/design-reviews/issues/814 >>> >>> TAG review status >>> >>> Pending >>> >>> Risks >>> Interoperability and Compatibility >>> >>> Gecko: Positive >>> >> >>> WebKit: No signal, but implementation under way >>> >> >>> Web developers: No signals >>> >> >> Well, I saw at least 1 positive signal >> <https://twitter.com/cramforce/status/1623155349837733888> passing by. >> I'm guessing you have partners lined up that can be counted as a positive >> signal as well? >> > > Indeed there's strong interest among language implementers (Kotlin, Dart, > Google's J2CL, OCaml). I wasn't sure what counts as a "web developer" > signal. > > >> >>> Other signals: Proposal is at Phase 3 in the Wasm CG, demonstrating >>> high levels of consensus, and implementations are under way in SpiderMonkey >>> and JSC. >>> >> >> You could have started with that :) I believe we concluded at some point >> that phase 3 proposals don't require specific vendor signal requests. >> > > It would be great if the tooling directly supported JS & Wasm features so > it would be clearer for folks trying to go by the letter of the process. > > >> >>> WebView application risks >>> >>> None >>> >>> Goals for experimentation >>> >>> Let developers compare in-the-wild performance of applications which >>> currently compile to JS to the same application compiled to WebAssembly GC. >>> And the same for framework developers with multiple export formats, >>> allowing their users to make the same comparisons. >>> >>> We are working with multiple partners who are committed to gathering >>> such data, and we plan to use it to validate that the design is sufficient >>> to meet our expectations around performance. >>> >>> Ongoing technical constraints >>> >>> None >>> >>> Debuggability >>> >>> Wasm GC is debuggable using devtools, including sourcemap support & >>> profiling. We expect support to improve over time as toolchain implementers >>> work on improving developer experience, analogous to what we currently have >>> with DWARF-based C++ debugging in Emscripten + the Devtools DWARF extension. >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, Chrome OS, Android, and Android WebView)? >>> >>> Yes >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? >>> >>> No. Instead, it is tested by Wasm spec tests, as is customary for core >>> Wasm features. >>> >>> Flag name >>> >>> WebAssembly Garbage Collection >>> >>> Requires code in //chrome? >>> >>> No >>> >>> Tracking bug >>> >>> https://bugs.chromium.org/p/v8/issues/detail?id=7748 >>> >>> Launch bug >>> >>> https://launch.corp.google.com/launch/4231622 >>> >>> Estimated milestones >>> >>> OriginTrial >>> >>> TBD based on partner readiness >>> >> >> How many milestones are you planning to run the OT for? That can be >> helpful to know even if you don't know the exact milestone you'd start with. >> > > We'd like to run for the maximum normally allowed, which per > https://www.chromium.org/blink/launching-features/#origin-trials sounds > like it's 6 milestones. There are a lot of moving pieces to experimenting > with Wasm features due to the layers involved (VM, toolchain, libraries, > application), so a longer trial would help us make sure we & our partners > gather as much data as we can. > > >> >> >>> >>> Link to entry on the Chrome Platform Status >>> >>> WasmGC: https://chromestatus.com/feature/6062715726462976 >>> >>> stringref: https://chromestatus.com/feature/5094457362350080 >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEvLGcJ40QGU0eOx6Y24RLQOwXWQFrPaTuqUw%2Bm2TSkiRMjWCw%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEvLGcJ40QGU0eOx6Y24RLQOwXWQFrPaTuqUw%2Bm2TSkiRMjWCw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEvLGcLk-1y%2BayzApv_3%2BS5PQ1UfKbXg7XFsfdm9eWSXaDm0Gg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEvLGcLk-1y%2BayzApv_3%2BS5PQ1UfKbXg7XFsfdm9eWSXaDm0Gg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEvLGcKgXsdWYpCL2NHo3PGEsEF7z11DOiDAQ%3DesHZH40kPcKg%40mail.gmail.com.
