Dear API owners, Our origin trial on supporting JS Strings in Wasm <https://developer.chrome.com/origintrials/#/view_trial/2142587522721513473> (JS String Builtins <https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md> 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 <https://docs.google.com/document/d/1zL9goDsawTQUFuuQ8ddI_pUcLY1_iFOsHaDZ374dnGw/edit?usp=sharing> 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 <https://docs.google.com/presentation/d/1gbyQz0nbLJJ07lbi8iuLHSchQ2-fH29UXS5ebLnG0ZU/edit#slide=id.g1ef40614c6f_0_0> 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) <https://github.com/WebAssembly/stringref/blob/main/proposals/stringref/Overview.md> that this one will replace. - *More experimentation* *with respect to string constants *around binary size, memory overhead and initialization performance is required. Several options <https://docs.google.com/document/d/12Kxqfg56few1NNH0qcF0KsGh8L2QVGox0ldpEabJDOA/edit> 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 emailsecmzieg...@chromium.org, jkumme...@chromium.org, ad...@chromium.org ExplainerNone 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 componentBlink>JavaScript>WebAssembly <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly> TAG reviewNone TAG review statusNot applicable Chromium Trial NameWebAssemblyJSStringBuiltins 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?No Flag name on chrome://flagsNone Finch feature nameNone Non-finch justificationNone 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 discussionsIntent 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 <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 blink-dev+unsubscr...@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.
