Intent to Experiment: WebAssembly Garbage Collection (WasmGC), plus stringref

[Adam Klein]

Contact emails

ad...@chromium.org, jkum...@chromium.org

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

Search tags

wasm, webassembly, gc, managed objects, 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

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.

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?

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

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.

[Yoav Weiss]

This is super exciting!! Thanks for working on this :)

+Jason Robbins - FYI, this intent also didn't show up in our tooling..

Well, I saw at least 1 positive signal passing by. I'm guessing you have partners lined up that can be counted as a positive signal as well?

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.

 

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?

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.

 

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.

--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEvLGcJ40QGU0eOx6Y24RLQOwXWQFrPaTuqUw%2Bm2TSkiRMjWCw%40mail.gmail.com.

[Adam Klein]

On Thu, Feb 9, 2023 at 1:32 AM Yoav Weiss <yoav...@chromium.org> wrote:

This is super exciting!! Thanks for working on this :)

+Jason Robbins - 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.

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.

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.

[Mike Taylor]

LGTM to experiment w/ an OT for 6 milestones.

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.

[Adam Klein]

We're now starting the ball rolling on the WasmGC Origin Trial, so we expect the 6 milestone approval to cover M111 - M116.

[Mike Taylor]

Thanks for the update, Adam.

[Adam Klein]

Due to unforeseen configuration issues internal to V8, we're now targeting M112 as the first milestone for this Origin Trial (running through M117).