Thanks for the reply, Mike. I'm going to fill in some of this to avoid blocking over the weekend.
On Fri, Sep 15, 2023 at 1:26 PM Mike Taylor <[email protected]> wrote: > On 9/12/23 9:22 PM, 'Emanuel Ziegler' via blink-dev wrote: > > Dear API owners, > > > Following the continued experiment for Garbage Collected WebAssembly > (WasmGC), we plan to ship the feature in M119 after the positive vote to > phase 4 by the WebAssembly Community Group today. > > The feature has shown very good performance with reasonable compromises. > The findings from the origin trial are summarized in a public document > <https://docs.google.com/document/d/1KsbQLh_RzM9ixF6bzmJwyRMQLE-rSFlz_zNoGv-EITY/edit?usp=sharing> > . > > This feature is tied to the Function References > <https://github.com/WebAssembly/function-references> proposal which is a > de-facto part of WasmGC (no current use outside of the proposal, hard > requirement for WasmGC) and only listed as a separate proposal for historic > reasons. The Function References proposal has therefore also been voted to > phase 4 on the same day as WasmGC. > > We plan to launch the feature in the following manner: > > 1. > > End the current origin trial with M118 as its last milestone > 2. > > Refactor the binary instruction representation to match the final spec > (incompatible change) > 3. > > Ship the feature with M119 > > This plan sounds good. Thx. > > > Our data from the trial has shown that there is a need for fast string > interoperability with JS that this proposal does not address. We plan to > launch a new experiment investigating different approaches to this problem > (see separate I2E mail). > > > Contact emails [email protected], [email protected] > > Explainer > https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md > > https://github.com/WebAssembly/function-references/blob/main/proposals/function-references/Overview.md > > Specification https://github.com/WebAssembly/gc/tree/main/proposals/gc > > 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. In > Chrome, enabling this feature implies enabling Typed Function References, > which allow function references to be stored in the aforementioned structs > and arrays. > > > 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 Issues addressed > > Risks > > > Interoperability and Compatibility > > *Gecko*: Positive > > *WebKit*: No signal > > Can we request a signal? > https://github.com/WebKit/standards-positions/issues/new/choose > Since this is a Phase 4 proposal within the Wasm CG, the process does not normally require a signal, as documented in https://bit.ly/blink-signals. Are you requesting an exception-to-the-exception here? FWIW an implementation is well underway, tracked at https://bugs.webkit.org/show_bug.cgi?id=247394. > > > *Web developers*: Positive Google Sheets, which is currently compiling > Java to JavaScript, is experimenting with using WasmGC to speed up their > calculation engine. JetBrains is working on a Kotlin -> WasmGC compiler. > Dart is working on a Dart -> WasmGC compiler, in collaboration with Flutter. > > *Other signals*: > > WebView application risks > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > > > Debuggability > > Can you say more about this? > Copying what I wrote in the original Intent to Experiment <https://groups.google.com/a/chromium.org/g/blink-dev/c/HDbvHCVFSW0/m/YKheArEAAgAJ> : 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)? No > > Can you say more about this? > This was a data entry error, the feature *is* supported on all Blink platforms. > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? No > > In this case, is this new feature covered by existing wasm test suites? > Yes, like all Wasm proposals it's covered by spec tests that are part of the proposal. > > Flag name on chrome://flags > > Finch feature name None > > Presumably this is behind a feature, if an Origin Trial occured, right? > Yes. The Blink runtime enabled feature is called "WebAssemblyGC". > > Non-finch justification > > The feature does not enable any functionality without the module being > explicitly compiled for that feature. We therefore chose to use an origin > trial to evaluate its suitability and stability. This allowed websites that > want to try this feature to opt in and do their own A/B comparisons. > > > Requires code in //chrome? False > > Tracking bug https://bugs.chromium.org/p/v8/issues/detail?id=7748 > > Launch bug https://launch.corp.google.com/launch/4231622 > > Estimated milestones > OriginTrial desktop last 120 > OriginTrial desktop first 112 > OriginTrial Android last 120 > OriginTrial Android first 112 > > Anticipated spec changes > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/6062715726462976 > > Links to previous Intent discussions Intent to Experiment: > https://groups.google.com/a/chromium.org/g/blink-dev/c/HDbvHCVFSW0 > Intent to Extend Experiment: > https://groups.google.com/a/chromium.org/g/blink-dev/c/7F_daEqGQAY > Intent to Ship: > https://groups.google.com/a/chromium.org/g/blink-dev/c/7F_daEqGQAY > > > 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/CAPAU7RzPfx-CgUJbWOhiCpFkhr1myZNVS8c4N3YUcLT538dcJQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAU7RzPfx-CgUJbWOhiCpFkhr1myZNVS8c4N3YUcLT538dcJQ%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/CAEvLGc%2B_PnX%3DTXosOwV%3DcpTOCr0w16Xi940o7Rc3%3DWiEm%2BnKoQ%40mail.gmail.com.
