LGTM2 - thanks Adam.
On 9/16/23 7:39 AM, Yoav Weiss wrote:
LGTM1
On Fri, Sep 15, 2023 at 11:13 PM Adam Klein <[email protected]> wrote:
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?
I don't think an exception to the exception is needed here.
Nah, that's just me forgetting the exceptions. :) Thanks for reminding me.
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEvLGc%2B_PnX%3DTXosOwV%3DcpTOCr0w16Xi940o7Rc3%3DWiEm%2BnKoQ%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/221fb42e-d5f9-424b-97db-82b34b66bf86%40chromium.org.
