Intent to Extend Experiment: WebAssembly JS String Builtins

[Emanuel Ziegler]

Dear API owners,

We would like to request an extension of the origin trial for Wasm JS String Builtins. There were recent changes to the initialization of string constants (implicit imports) which improved startup time and binary size on local measurements.

We would like to use the experiment to verify the viability of this change in the wild (effect on load and startup times) and upcoming changes to it (variable import namespace for greater flexibility). Sheets/J2Wasm already implemented the first part and wants to roll it out to users in the next weeks as part of the origin trial.

The proposal is progressing well along the requested dimensions

• Draft spec (early draft is ok, but must be spec-like and associated with the appropriate standardization venue, or WICG)
• The proposal continues to be actively maintained and changed with plenty of community engagement.
• Recent changes mostly affected string constants and their initialization.
• TAG review (see exceptions)
• A TAG review has been requested and is scheduled for discussion.
• bit.ly/blink-signals requests
• Firefox/SpiderMonkey is actively working on their prototype and the champion behind this proposal.
• Safari/JSC expressed openness to the proposal but no official confirmation yet.
• Outreach for feedback from the spec community
• The proposal (including string constant changes) was voted to phase 3 at the on-site Wasm CG meeting on June 5 with unanimous consent.
• WPT tests
• WPTs will likely be added based on the already existing JS API tests in the proposal repository (see GitHub issue 33 on the proposal repository on this question).

More details on some of these items can be found in the updated experiment summary.

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

Pending

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 (https://github.com/WebKit/standards-positions/issues/343)

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	127
Origin trial extension 1 end milestone	127

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6695587390423040?gate=5106659883220992

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
Intent to Extend Experiment 1: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAU7RyYPNTcmt1uHe279qW46ff3S%3DZ-M%3DHZjKn%3DK%2Bgp_0DyZw%40mail.gmail.com?utm_medium=email&utm_source=footer
Intent to Ship: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAU7RyYPNTcmt1uHe279qW46ff3S%3DZ-M%3DHZjKn%3DK%2Bgp_0DyZw%40mail.gmail.com?utm_medium=email&utm_source=footer

This intent message was generated by Chrome Platform Status.

[Domenic Denicola]

On Thu, Jul 4, 2024 at 2:50 AM Emanuel Ziegler <ecmzi...@chromium.org> wrote:

Dear API owners,

We would like to request an extension of the origin trial for Wasm JS String Builtins. There were recent changes to the initialization of string constants (implicit imports) which improved startup time and binary size on local measurements.

We would like to use the experiment to verify the viability of this change in the wild (effect on load and startup times) and upcoming changes to it (variable import namespace for greater flexibility). Sheets/J2Wasm already implemented the first part and wants to roll it out to users in the next weeks as part of the origin trial.

The proposal is progressing well along the requested dimensions

• Draft spec (early draft is ok, but must be spec-like and associated with the appropriate standardization venue, or WICG)
• The proposal continues to be actively maintained and changed with plenty of community engagement.
• Recent changes mostly affected string constants and their initialization.

To me, the proposal document does not seem very "spec-like", but instead like an explainer. Is there a formal specification available?

 

• TAG review (see exceptions)
• A TAG review has been requested and is scheduled for discussion.
• bit.ly/blink-signals requests
• Firefox/SpiderMonkey is actively working on their prototype and the champion behind this proposal.
• Safari/JSC expressed openness to the proposal but no official confirmation yet.
• Outreach for feedback from the spec community
• The proposal (including string constant changes) was voted to phase 3 at the on-site Wasm CG meeting on June 5 with unanimous consent.
• WPT tests
• WPTs will likely be added based on the already existing JS API tests in the proposal repository (see GitHub issue 33 on the proposal repository on this question).

Is there anything preventing you from upstreaming those tests to the web platform tests repository now?

 

--
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/CAPAU7RzGQhi3m4g_rTQt79LFFz6mdmT%3D8YRVomA4UwAVcZQtrA%40mail.gmail.com.

[Emanuel Ziegler]

Thanks for taking a look! The progress is in alignment with the Wasm spec process requirements. Please see my answers below where I provide more background.

On Mon, Jul 8, 2024 at 6:04 AM Domenic Denicola <dom...@chromium.org> wrote:

On Thu, Jul 4, 2024 at 2:50 AM Emanuel Ziegler <ecmzi...@chromium.org> wrote:

Dear API owners,

We would like to request an extension of the origin trial for Wasm JS String Builtins. There were recent changes to the initialization of string constants (implicit imports) which improved startup time and binary size on local measurements.

We would like to use the experiment to verify the viability of this change in the wild (effect on load and startup times) and upcoming changes to it (variable import namespace for greater flexibility). Sheets/J2Wasm already implemented the first part and wants to roll it out to users in the next weeks as part of the origin trial.

The proposal is progressing well along the requested dimensions

• Draft spec (early draft is ok, but must be spec-like and associated with the appropriate standardization venue, or WICG)
• The proposal continues to be actively maintained and changed with plenty of community engagement.
• Recent changes mostly affected string constants and their initialization.

To me, the proposal document does not seem very "spec-like", but instead like an explainer. Is there a formal specification available?

This is in accordance with common practice and in line with the Wasm proposal workflow. To quote from the official documentation for phase 3:

"Updates on the actual spec document and reference interpreter are NOT yet required"

Instead they only happen during phase 3 in preparation for phase 4 (final stage). Until then, the overview/explainer document is the main source of truth to avoid double maintenance. Spec changes also often require the assistance of a Wasm spec expert and we want to keep the overhead for those low. The overhead of maintaining spec updates will hopefully improve in a year or two with the planned switch to SpecTec which will make the spec more accessible to proposal champions and implementers.

• TAG review (see exceptions)
• A TAG review has been requested and is scheduled for discussion.
• bit.ly/blink-signals requests
• Firefox/SpiderMonkey is actively working on their prototype and the champion behind this proposal.
• Safari/JSC expressed openness to the proposal but no official confirmation yet.
• Outreach for feedback from the spec community
• The proposal (including string constant changes) was voted to phase 3 at the on-site Wasm CG meeting on June 5 with unanimous consent.
• WPT tests
• WPTs will likely be added based on the already existing JS API tests in the proposal repository (see GitHub issue 33 on the proposal repository on this question).

Is there anything preventing you from upstreaming those tests to the web platform tests repository now?

No, it wasn't a priority so far and is not required at all by the Wasm proposal process. Wasm engines don't use them as their primary correctness verification method. That's what Wasm spec tests are used for which have been added during phase 2 in alignment with the requirements. The use of WPTs for the browser community lies mostly in making support (or lack of it) transparent to web developers. As such, they are usually created once the feature is sufficiently stable to avoid extra maintenance and noise generated from updates and inconsistencies in between WPTs and Wasm spec tests. If you think there would be a benefit in merging them now, we can raise that with the proposal champion.

[Domenic Denicola]

Thanks for clarifying the Wasm process. It sounds like there's some mismatch between its more lax requirements, and the requirements of the Blink process for shipping things in Chromium, and in particular the requirements for extending an experiment.

It sounds like it would be easy to make progress on the WPTs requirement, but potentially not very useful for the community, if all the Wasm engines are using the existing JS API tests and not paying attention to WPTs until a later stage. And, it would be hard to make progress on the spec requirement.

I'm inclined to approve the extension, as it's clear you all are making a good-faith effort to shape this feature in response to developer and implementer feedback and using the experiment framework as intended. However, since it contradicts the letter of the process, please give us a day or so to discuss amongst API owners and make sure others are OK with this kind of exception. And maybe, as Mike mentioned during the last extension, we should codify some of these exceptions into the Blink process to avoid the clash in the future.

[Yoav Weiss (@Shopify)]

LGTM to experiment until M127, inclusive.

After some discussions amongst the API owners, I think there's no real mismatch.

The Blink process does have more requirements for OT renewals than the WASM process does for stage 3 proposals, but that not necessarily a contradiction.

Therefore I would have expected y'all to make progress on a spec regardless of the WASM process stage before asking for this renewal.

At the same time, given that the requirements may have not been very clear, I don't want this to be a blocker here.

But if another extension is needed, I'd expect to see some significant progress on both the spec and WPT-streaming front.

Contact emailsecmzi...@chromium.org, jkummer...@chromium.org, adamk@chromium.org

ExplainerNone

Specificationhttps://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 componentBlink>JavaScript>WebAssembly

TAG reviewNone

TAG review statusPending

Chromium Trial NameWebAssemblyJSStringBuiltins

Link to origin trial feedback summaryhttps://docs.google.com/document/d/1zL9goDsawTQUFuuQ8ddI_pUcLY1_iFOsHaDZ374dnGw/edit?usp=sharing

Origin Trial documentation linkhttps://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md

Risks

Interoperability and Compatibility

None

Gecko: Positive

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/343)

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://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Estimated milestonesOrigin trial desktop first119Origin trial desktop last127Origin trial extension 1 end milestone127

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/6695587390423040?gate=5106659883220992

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

Intent to Extend Experiment 1: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAU7RyYPNTcmt1uHe279qW46ff3S%3DZ-M%3DHZjKn%3DK%2Bgp_0DyZw%40mail.gmail.com?utm_medium=email&utm_source=footer
Intent to Ship: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAU7RyYPNTcmt1uHe279qW46ff3S%3DZ-M%3DHZjKn%3DK%2Bgp_0DyZw%40mail.gmail.com?utm_medium=email&utm_source=footer

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+unsubscribe@chromium.org.

[Emanuel Ziegler]

Just to clarify: the current OT already runs until M127 inclusive, we are asking for an extension to M130.

Also, there was significant progress on the spec since the last extension. The proposal has moved from phase 2 to phase 3 since then including fulfilling all the requirements for that transition. Only the formal spec is lacking and will be completed in the upcoming months before reaching phase 4.

Thanks,

    Emanuel

[Yoav Weiss (@Shopify)]

LGTM to extend experimentation until M130 inclusive

On Thu, Jul 11, 2024 at 1:54 PM Emanuel Ziegler <ecmzi...@chromium.org> wrote:

Just to clarify: the current OT already runs until M127 inclusive, we are asking for an extension to M130.

Ok, that wasn't clear from your intent, but I should have asked for clarifications on that front. Apologies!

 

Also, there was significant progress on the spec since the last extension. The proposal has moved from phase 2 to phase 3 since then including fulfilling all the requirements for that transition. Only the formal spec is lacking and will be completed in the upcoming months before reaching phase 4.

The Blink process cares less about phase transitions (prior to phase 4, which we use to gauge consensus) and more about actual specifications.