Piotr Sarnacki (Oct 20 2024 at 14:37): Piotr Sarnacki (Oct 20 2024 at 14:37):Hi, I've been playing more with WASM and I'm now introducing strigref proposal to some of my experiments. I know that V8 and some other runtimes implement stringref already, but I haven't seen any mention of the proposal in the project nor issues. Are there any plans to implement it or is maybe someone working on it already?
Alex Crichton (Oct 20 2024 at 14:53):No plans currently, or at least not as far as I'm aware of myself.
Piotr Sarnacki (Oct 21 2024 at 11:46):I was researching the subject a bit more and found this comment saying stringref has uncertain future. I'm guessing this might be the reason it's not implemented in most runtimes yet :thinking: For anyone else looking for a string solution, it seems like this is the way to go for now: https://github.com/WebAssembly/js-string-builtins. More info about that can also be found on the feature page for Chromium, which also links to discussion about trial and trial extension for the feature.
Piotr Sarnacki (Oct 21 2024 at 14:17):One small addition/question here - if anyone is aware of any activity and or plans regarding the stringref proposal itself, I would be very much interested to hear about it. I haven't really had time to experiment with JS String builtins, but it looks to me like stringref would be a nicer thing to have when writing raw WASM code rather than String builtins.
Piotr Sarnacki (Oct 21 2024 at 15:26):Sorry for spamming this topic, but I have an additional question. @Alex Crichton given an uncertain future of the stringref proposal, do you think a PR with stringref implementation could be accepted to WasmTime? I'm not sure if I have time to work on it in the near future, but I just wanted to know if it's even feasible to get it into WasmTime behind a flag? Or would it only be accepted once the proposal is in phase 3?
fitzgen (he/him) (Oct 21 2024 at 18:16):in general, this should be handled at the language's wasm toolchain level, where they make the following consideration:
(array i8) (assuming utf8/byte-encoding; could use (array i16) for utf16 and 16-bit encodings)the stringref proposal was in an uncanny valley where it was baking the semantics of JS strings into the wasm language, which is problematic for situations like Wasmtime's where the Wasm is not running inside of a JS engine.
the JS string ref proposal is actually really nice for toolchains that are always JS-specific because it gives them a path for future JS-specific imports as well, like JS regexes and JS dates and such. it gives them access to a bunch of JS stuff that would never make sense for, e.g., Wasmtime to implement.
fitzgen (he/him) (Oct 21 2024 at 18:27):(err s/JS string ref/JS string builtins/ in the previous message, too late to edit)
Piotr Sarnacki (Oct 21 2024 at 18:42):Thanks for more context @fitzgen (he/him)
I now have one more question about JS string builtins, though. After reading the proposal overview I thought that technically any language could expose JS string builtins to the guest, ie. it could be done in Wasmtime too. I thought it could make sense not because it's allowing to access Javascript functions, but because it makes a standardised set of functions and types available to the guest, which in turn allows to write WASM programs easier. Are you saying that this is not the case and it's unlikely that non-JS runtimes like Wasmtime will get support for JS string builtins?
Lann Martin (Oct 21 2024 at 19:29):If I'm recalling correctly, Wasmtime wouldn't need to explicitly support js string builtins; any host could implement them without new functionality (modulo GC implementation completeness)
fitzgen (he/him) (Oct 21 2024 at 20:35):one could implement the JS string builtins as functions defined on a wasmtime::Linker, there is nothing preventing that
it is unlikely that Wasmtime will ever have built-in support for these functions and special case them in the compiler to inline them and all that stuff that you would expect a browser's wasm engine to do
Piotr Sarnacki (Oct 22 2024 at 08:38):Ok, I see, so essentially it is technically possible, but unlikely. That's a bit of a bummer - better string support would be great for non-browser workloads too.
Chris Fallin (Oct 22 2024 at 15:37):FWIW (you may be aware but just to make it explicit) -- nothing prevents a good, performant string implementation inside a Wasm module, or with GC, even passed by reference between modules, or with wit and resources, passed by reference between components. The main motivation for stringref and then JS string builtins is to provide access to the JavaScript strings on a host that has JS and Wasm (i.e., browsers), which Wasmtime isn't
Chris Fallin (Oct 22 2024 at 15:38):In other words, driven by interop need with JS, and there's no interop with JS on Wasmtime, so instead language runtimes are fine (and even prefer, because it's less work) using their existing string impls.
Chris Fallin (Oct 22 2024 at 15:41):From the point of view of "making it easier to write Wasm programs" -- Wasm is mainly optimized to be a compiler target, and so aims for a minimal floor of functionality needed to performantly use hardware primitives, rather than a ceiling of functionality for convenience. It's perfectly fine for folks to put together convenience libraries or other tooling on top (and BA effectively has, with the FFI-related tooling!)
Piotr Sarnacki (Oct 23 2024 at 08:38):Sure, I know most of the time you compile stuff into WASM, but I'm doing something different at the moment. I'm experimenting with compiling a subset of Javascript into WASM GC code and something like the stringref proposal would make it a whole lot easier. Ie. I know I can generate the implementation of JS strings and all the methods it supports into WASM using i8 arrays, but with stringref most of the work would have been already done.
I guess maybe it's also the fact that for now it's not even a proof of concept yet, so I'm doing the simplest thing possible - just some string manipulation to generate working WASM code. When I know it has future I'll probably try to abstract it a bit more, so it's easier to write the methods I need.
Piotr Sarnacki (Oct 23 2024 at 09:24):Actually this discussion motivated me to do it properly from the start. I'm honestly not sure how much more code I have to do to validate the idea (like even how functions work), so I'll rewrite what I have into a proper AST generator for WASM and I'll generate WASM code from the AST. That way I'll be able to combine WASM code generation functions much easier.
Milan (Oct 23 2024 at 14:52):Piotr Sarnacki said:
[...] I'm experimenting with compiling a subset of Javascript into WASM GC code [...]
If you haven't seen porffor for AoT JS compilation to WASM that might be a good starting point (recently got 50% Test262 coverage!): https://github.com/CanadaHonk/porffor
Piotr Sarnacki (Oct 23 2024 at 16:11):@Milan yeah, I've seen porffor and it's a very interesting project for sure! I decided to experiment by writing a project from scratch mainly because I wanted to learn more about WASM in general, and explore proposals like WASM GC, exception handling, and tail call optimizations. Writing a JS compiler seems like a great thing to hit all of these, but one of the rules that porffor follows is: "Porffor intentionally does not use Wasm proposals which are not commonly implemented yet (eg GC) so it can be used in as many places as possible.". Also I write JavaScript only when I absolutely have to :sweat_smile:
If I get anywhere I will maybe try to run some comparisons between the tools, like compare the size of the generated code, performance etc as I think it might be an interesting way to evaluate the usefulness of WASM proposals for using dynamic languages on top of WASM.
Last updated: Dec 23 2024 at 13:07 UTC