Intent to Experiment: WebAssembly JS String Builtins
Emanuel Ziegler
Dear API Owners,
Many use cases for WasmGC require calling JS functions or WebAPIs frequently. These calls suffer from substantial overhead when strings are involved due to the encoding/decoding required for changing in between the non-standardized Wasm module representation and the engine-internal JS string representation.
We previously evaluated native string operations in Wasm which would map to JS equivalents and use the same backend, eliminating the need for re-encoding and copies. While the performance of this approach was excellent (see e.g. Kotlin/Wasm's DBMonster benchmark with and without stringref), the Wasm Community Group preferred an alternative solution that uses imported JS functions for creating and manipulating strings which could then be optimized away by the engine. Our experiments show a similar peak performance but slightly lower performance on startup as Liftoff is not capable of doing such optimizations effectively falling back to executing the call.
We would therefore like to launch a 6-month origin trial starting in M119 for comparing the two approaches and, if performance is good enough, encourage partners to switch over to the new proposal to verify its viability.
Contact emails
ecmzi...@chromium.org, jkum...@chromium.org, ad...@chromium.orgExplainer
NoneSpecification
https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.mdSummary
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>WebAssemblyTAG review
NoneTAG review status
Not applicableRisks
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, Chrome OS, Android, and Android WebView)?
NoIs this feature fully tested by web-platform-tests?
NoFlag name on chrome://flags
NoneFinch feature name
NoneNon-finch justification
NoneRequires code in //chrome?
FalseEstimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6695587390423040
Daniel Bratell
Do you plan to run it as a finch experiment or do you have partners prepared for an Origin Trial?
/Daniel
--
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/CAPAU7RyzxKa0Pj6q7B_jyfT%3DH%2BSK264%3Dx8wn1ans%3D8UjHRhctQ%40mail.gmail.com.
Emanuel Ziegler
Daniel Bratell
LGTM for an origin trial M119-M124 (which I think is what you requested)
Good luck with your data collection!
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAU7Rym1c7E0Da82c8f3PKOac5hdTPQ1F575xjvfnuKEAD0cg%40mail.gmail.com.