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 On Thursday, March 14, 2024 at 1:29:57 PM UTC-4 Adam Klein wrote: > On Thu, Mar 14, 2024 at 8:45 AM Emanuel Ziegler <ecmzieg...@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 > >> >> - 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 >> <https://github.com/WebAssembly/js-string-builtins/issues> 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 >> >> On Tue, Mar 12, 2024 at 3:52 PM Mike Taylor <miketa...@chromium.org> >> wrote: >> >>> 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 >>> On 3/12/24 8:35 AM, Emanuel Ziegler wrote: >>> >>> 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 emails ecmzieg...@chromium.org, jkumme...@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 >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly> >>> >>> 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 >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? 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 >>> <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 >>> >>> <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> >>> . >>> >>> -- 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/c8be633b-82d0-4c72-ab5f-276b54686671n%40chromium.org.
