Specification for shared js-string-builtins

[Liedtke]

With the "shared-everything"-claim this proposal should also spec the change to the js-string-builtins proposal.

It might be enough to "simply" specify the new accepted signatures?

E.g. something like:

func equals(
  first: shared externref,
  second: shared externref
) -> i32

I would assume that each version should be either "all-shared" or "none-shared" meaning that the following signature should not be valid:

func equals(
  first: shared externref,
  second: externref
) -> i32

[eqrion]

Adding shared to the function types like that would break existing users (there's no subtyping relation between shared/unshared IIUC). So we'd either need this to be a new builtin collection (wasm:js-string-shared), or we'd need to make the builtin selection algorithm smarter and able to match the requested import to one of multiple signatures. I think either is workable.

However, is this necessary? Are JS strings and other primitives going to be come shareable with this proposal? I don't see that in the overview, so it'd be good to call that out if that's the intention.

If they're not shareable, then I think the existing signatures should work fine.

[jakobkummerow]

I agree that overloading the builtin functions (allowing two possible signatures) or duplicating them (in a new namespace, or as "wasm:js-string" "shared-equals" etc) both work. I'd lean towards the former since it feels more elegant, but both choices are easy to implement.

Re necessity, two points:
(1) Wasm needs strings. Shared Wasm will still need strings. Shared Wasm structs need the ability to have fields whose values are strings; but shared structs can't point at non-shared values. So since imported strings are the only strings we have, we'll have to create shared versions of them now, typed as shared externref. And if we still want to be able to create, compare, concatenate, etc, these strings, we need versions of the string builtins that can operate on them.
(2) There is a JavaScript (Shared) Structs proposal that also postulates that JS primitives will be shareable. I think Shu currently has other priorities, but as soon as someone has time to pick up that proposal again, that'll be another reason for shared JS strings to become a thing. (In fact, one possible motivation to drive that proposal forward is Wasm: it might be a crucial building block for smooth JS interop for shared Wasm objects.)

Of course we can also use the opportunity to revive the Wasm stringref proposal, if you prefer :-)

[Liedtke]

[...] or we'd need to make the builtin selection algorithm smarter and able to match the requested import to one of multiple signatures

That was my assumption and as an import wasm:js-string:equals also needs to specify a signature, it shouldn't need any smart overload resolution, just checking if the specified signature is in one of the allowed signatures (e.g. for equals either with two shared externref or with two externref.)

However, is this necessary? Are JS strings and other primitives going to be come shareable with this proposal?

Due to the shared-"everything" approach, the only option for users (toolchains) will be to basically specify their whole type hierarchy as shared. If they want to use JS-strings as their string primitives (which in many cases I think is useful as it allows the best interop with JavaScript), then strings will need to be shareable.

In our incomplete WIP prototype implementation not only strings are shareable but we also allow undefined, true, false and numbers to be shared (but not symbol and not bigint). This is mostly based on the JS shared-structs proposal / its prototype implementation in V8.

That proposal mentions:

Except for strings, sharing primitives in the engine is usually trivial, especially for NaN-boxing implementations.

I am not sure why bigint would be trivial (maybe because they don't have different shapes compared to strings?) but independently bigint and symbols aren't supported in V8, yet, AFAICT. Assuming that JS shared-structs will not move forward very quickly, it would also be a requirement for this proposal to define which JS types are actually allowed to be passed into a shared externref?

And I guess limiting it to "shared wasm structs, arrays, i31refs and JS strings" would be a viable answer given that there isn't a clear use case for wasm to use any of the other JS primitives other than for passing it from and to JS (which it could just use thread-local tables and indices for).

[eqrion]

@jakobkummerow Yeah, it makes sense that shared JS strings would be useful for shared wasm-GC. I'm mostly trying to get a clarification if this proposal is requiring that JS strings (or other JS primitives) become shareable, or if that's a different proposal. I think it technically could be specified in this proposal because JS primitives don't have identity and so the wasm JS-API could just allow the values to flow between threads.

I don't think stringref will make this situation any easier. The work to support this isn't in the frontend, but the actual VM machinery which is the same for stringref and shared externref.

At least for SpiderMonkey, we expect shared JS strings (and other allocated primitives like bigint/symbols) to be a ton of work. So if it's required in this proposal that would be good to know for sizing purposes.

[eqrion]

If you want to pick something for experimentation, I would just allow the builtin selection algorithm to pick through one of multiple function signatures. It has come up independently with some other ideas for builtins.

[vouillon]

And I guess limiting it to "shared wasm structs, arrays, i31refs and JS strings" would be a viable answer given that there isn't a clear use case for wasm to use any of the other JS primitives other than for passing it from and to JS (which it could just use thread-local tables and indices for).

With Wasm GC, the garbage collector automatically keeps track of which JavaScript objects are referenced from Wasm. This is not the case with thread-local tables, right?

[jakobkummerow]

trying to get a clarification if this proposal is requiring that JS strings (or other JS primitives) become shareable

I assume so. Generally speaking, it's the burden of every new proposal to define how the new feature interacts with all existing features, and as you know JS String Builtins are part of Wasm 3.0 now. It would be a weird and rather severe limitation if you could share all your structs but then lost the ability of those structs to refer to strings.

I don't think stringref will make this situation any easier. The work to support this isn't in the frontend, but the actual VM machinery which is the same for stringref and shared externref.

Agreed. And it was and still is a lot of work for us as well.

[tlively]

The overview already calls out strings as shareable in the JS API section:

JS Strings can be converted to shared externref since they are shareable according to the JS shared structs proposal.