JS String Builtins for WebAssembly

[ajklein]

こんにちは TAG-さん!

I'm requesting a TAG review of JS String Builtins for WebAssembly.

JavaScript runtimes have a rich set of builtin objects and primitives. Some languages targeting WebAssembly may have compatible primitives and would benefit from being able to use the equivalent JavaScript primitive for their implementation. The most pressing use-case here is for languages who would like to use the JavaScript String type to implement their strings. This proposal aims to provide a minimal and general mechanism for importing specific JavaScript primitives for efficient usage in WebAssembly code.

This is done by first adding a set of wasm builtin functions for performing JavaScript String operations. These builtin functions mirror a subset of the JavaScript String API and adapt it to be efficiently callable without JavaScript glue code. Then a mechanism for importing these wasm builtin functions is added to the WebAssembly JS-API. These two pieces in combination allow runtimes to reliably emit optimal code sequences for JavaScript String operations within WebAssembly modules. In the future, other JS builtin objects or JS primitives can be exposed through new wasm builtins.

• Explainer (minimally containing user needs and example code): https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md
• Specification URL: Formal spec not yet complete, but the above Overview specifies the feature thoroughly enough for Wasm Phase 2 requirements.
• Tests: Not yet available; will be included before Phase 3
• User research: N/A
• Security and Privacy self-review: N/A
• Primary contacts (and their relationship to the specification):
  • Ryan Hunt (@eqrion), Mozilla/SpiderMonkey, proposal champion
  • Adam Klein (@ajklein), Google/Chromium/V8, proposal collaborator
• Organization(s)/project(s) driving the specification: WebAssembly Community Group, Mozilla, Google
• Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification:
  • WebAssembly CG meeting notes:
    • https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-05-23.md
    • https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-06-06.md
    • https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-07-18.md
    • https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-10.md#update-on-js-string-builtins-ryan-hunt
    • https://github.com/WebAssembly/meetings/blob/main/main/2024/CG-01-16.md
  • Supported by both Mozilla and Google as implementers of browser engines supporting WebAssembly
  • Desired by toolchain implementers targeting WasmGC: J2Wasm, Kotlin, Dart
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • Chrome Status

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: Planning to move to Phase 3 by June 2024
• The group where the work on this specification is currently being done: WebAssembly Community Group
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WebAssembly Working Group
• Major unresolved issues with or opposition to this specification: N/A
• This work is being funded by: Mozilla, Google

You should also know that...

The current design is a result of extensive discussion in the Wasm CG over the past year (see above meeting notes), and follows a previous approach to dealing with strings directly in core Wasm, https://github.com/WebAssembly/stringref, which faced significant opposition in the CG.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify eqrion and ajklein

[littledan]

Some context about this design space and alternatives considered: https://wingolog.org/archives/2023/10/19/requiem-for-a-stringref

Bloomberg previously sponsored work towards the WebAssembly stringref proposal. At this point, we aren’t pushing for one alternative over another. I am just happy to see something moving forward for zero-copy strings in WebAssembly.

[plinss]

Thank you for your patience while waiting for us to take a look at this.

The TAG currently lacks domain expertise in the internals of JavaScript and WASM implementations, so we're ill-equiped to do a deep dive here. You've clearly put a ton of effort into this, and your document more than adequately addresses the handful of things that came to our minds while reviewing it. We don't see any obvious issues with the proposal as it stands.

We'll close this review for now. Please let us know if your design substantively changes, and we'll take another look.