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.
None
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
None
None
Origin trial desktop first | 119 |
Origin trial desktop last | 127 |
Origin trial extension 1 end milestone | 127 |
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).
--
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.
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?
"Updates on the actual spec document and reference interpreter are NOT yet required"
- 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?
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
SummaryThis 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 CompatibilityNone
Gecko: Positive
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/343)
Web developers: No signals
Other signals:
WebView application risksDoes 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 constraintsNone
DebuggabilityNone
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=footerThis 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.
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.