Intent to Experiment: WebAssembly JS String Builtins

[Emanuel Ziegler]

Dear API owners,

Our origin trial on supporting JS Strings in Wasm (JS String Builtins for Wasm) has reached its final milestone and we would like to continue to experiment with it.

The current status of the proposal and our experiments is as follows:

• The proposal is progressing well and has reached phase 2 on January 16 with overwhelming support by the community group (17 votes strongly in favor, 11 votes in favor, 4 neutral and no votes against).
• Performance of native support for JS strings in J2Wasm, Kotlin and Dart continues to look highly promising, making this a top priority for us to finalize the proposal and ship it in Chrome this year.
• There were a series of changes to the proposal and its API leading up to the vote which since then have all been implemented in V8.
• Sheets and J2Wasm started experimentation on the proposal and we expect in-the-wild performance numbers of the new API within the next weeks, comparing this with the previous proposal (StringRef) that this one will replace.
• More experimentation with respect to string constants around binary size, memory overhead and initialization performance is required. Several options are available regarding their implementation in the current proposal.
  
• Rollout of Sheets experiments is currently at 20% of production users offering us a wide number of real-world use cases.

We would therefore like to extend the origin trial by another 6 milestones, effectively ending it with M130. This is taking into account the long turnaround times required to test any API change between proposal changes, their implementation in Chrome, Binaryen, J2Wasm and Sheets until we can update the experiment and gather new data. We expect to reach phase 3 within the next months and want to use the data to inform the final shape of the proposal to be voted to phase 4, hopefully before the end of the year.

Thank you,

    Emanuel

Contact emails

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

Explainer

None

Specification

https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md

Summary

This feature exposes common JS string operations for easy import into WebAssembly and optimizations thereof. This allows creating and manipulating JS strings from WebAssembly without native support within WebAssembly while still allowing for a similar performance as native string references. The mechanism works by exposing suitably strict versions of JS string operations in the WebAssembly JS API. These can be imported by modules using externref as a generic data type for storing the strings. The engine can identify that these imports can be represented by native graph operators without the need for calling into JS. This leads to a comparable peak performance as native string operations while allowing quick interoperability with JS since no copying at the boundary is required when calling into arbitrary JS functions that consume strings.

Blink component

Blink>JavaScript>WebAssembly

TAG review

None

TAG review status

Not applicable

Chromium Trial Name

WebAssemblyJSStringBuiltins

Link to origin trial feedback summary

https://docs.google.com/document/d/1zL9goDsawTQUFuuQ8ddI_pUcLY1_iFOsHaDZ374dnGw/edit?usp=sharing

Origin Trial documentation link

https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md

Risks

Interoperability and Compatibility

None

Gecko: Positive

WebKit: No signal

Web developers: No signals

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?

None

Goals for experimentation

Ongoing technical constraints

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

Origin trial desktop first	119
Origin trial desktop last	124

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6695587390423040

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAU7RyzxKa0Pj6q7B_jyfT%3DH%2BSK264%3Dx8wn1ans%3D8UjHRhctQ%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

Hi Emanuel,

For OTs, we can approve extensions for 3 milestones at a time, depending on the criteria set at https://www.chromium.org/blink/launching-features/#origin-trials. Would you mind summarizing progress in the various areas? It sounds like there is good engagement from the "spec community" already.

thx,
Mike

--
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/CAPAU7RyYPNTcmt1uHe279qW46ff3S%3DZ-M%3DHZjKn%3DK%2Bgp_0DyZw%40mail.gmail.com.

[Emanuel Ziegler]

Hi Mike,

We can limit it to 3 milestones then and request another extension once we get further with our experimentation on string constants, because I don't expect that this will be enough. Every change we make has a 2-3 months of turnaround time because of the multitude of parties (proposal change → Wasm Runtime + Wasm Tools implementation → Compiler toolchain implementation → Application recompilation and redeployment) involved to implement the feature end-to-end and their respective release schedules.

To summarize the progress along each dimension:

• As mentioned, there was progress on the draft spec and we had a community group vote on it with very strong support.
• We are planning on triggering a TAG review this week. But we don't intend to ship before reaching phase 4 of the proposal which would be covered in the exceptions anyway.
• The status of the Chrome Status entry is still up-to-date in that we have a very positive signal from Firefox (Mozilla is actually championing this proposal) with an active implementation and regular updates and no signal from Safari yet.
• The spec community is heavily involved through presentations to the community group and active discussions on the proposal itself.
• We don't have WPT tests yet, but they will be added before phase 3 as required by the proposal process.

Let me know if you have any further questions!

Best regards,

    Emanuel

[Adam Klein]

On Thu, Mar 14, 2024 at 8:45 AM Emanuel Ziegler <ecmzi...@chromium.org> wrote:

Hi Mike,

We can limit it to 3 milestones then and request another extension once we get further with our experimentation on string constants, because I don't expect that this will be enough. Every change we make has a 2-3 months of turnaround time because of the multitude of parties (proposal change → Wasm Runtime + Wasm Tools implementation → Compiler toolchain implementation → Application recompilation and redeployment) involved to implement the feature end-to-end and their respective release schedules.

To summarize the progress along each dimension:

• As mentioned, there was progress on the draft spec and we had a community group vote on it with very strong support.
• We are planning on triggering a TAG review this week. But we don't intend to ship before reaching phase 4 of the proposal which would be covered in the exceptions anyway.

Filed as https://github.com/w3ctag/design-reviews/issues/940 

[Mike Taylor]

LGTM to extend from M125 to M127 inclusive - thanks for all the updates on progress. And it's totally fine to come back and request another extension, with similar updates on progress of the aforementioned areas.

(As a side note, I think the API OWNERs would be open to a discussion on the possibility of renewing OTs for Wasm-related proposals for a longer-than-default period, given the unique constraints vs other platform primitives. If you'd like to pursue that, you could start a conversation on blink-api-owners-discuss@).

thx,
Mike

Contact emails

ecmzi...@chromium.org, jkummer...@chromium.org, adamk@chromium.org

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.