Piotr Sarnacki (Oct 11 2024 at 21:03): Piotr Sarnacki (Oct 11 2024 at 21:03):I found an excellent blog post by Lin Clark on running JS in WASM. Module linking is mentioned there as a potential way to lower the memory usage of JS interpreters. The module linking repo is inactive, though, as per the note in the proposal, which mentions the focus shifted towards the component model.
In recent weeks I've been experimenting with running JavaScript code as WASM modules and memory is one of the limits for many use cases. As an example 5000 of SpiderMonkey WASM instances takes about 20-25GBs of RAM and even a smaller interpreter like QuickJS is at 2GBs.
It would be a game changer if an interpreter could be loaded to memory as a component and shared between a number of instances running other components with memory being copied on write as needed. Is anything like that planned? Is it even feasible? Unfortunately I don't know much about WASM internals (I'm learning, though!), so I'm not sure if it's not a silly question.
Joel Dice (Oct 11 2024 at 21:21):That's a great question. There are two aspects to this:
libstarlingmonkey.so, a JS interpreter, to a .cwasm file once and reusing it. Code is immutable, so reuse is pretty trivial -- no CoW needed.The latter raises questions about reentrance, multithreading, CoW, etc., but the former is reasonably straightforward, as described in Linking.md.
Specifically, what we'd want is to create JS components which import e.g. libstarlingmonkey.so rather than bundle it. That would give Wasmtime a chance to compile libstarlingmonkey.so to a cwasm file once, load it once, and reuse it across an arbitrary number of components. AFAIK, Wasmtime has all the bits in place to support this; the blocker is shipping libstarlingmonkey.so and teaching componentize-js to emit components that import it.
Piotr Sarnacki (Oct 11 2024 at 23:24):@Joel Dice thanks so much for the explanation and the link! I'll read more about it. As a side note, I feel like search engines are less and less useful as I've been searching for info on component model and also specifically linking quite a lot today and this page never came up :see_no_evil:
Jeff Parsons (Oct 12 2024 at 00:56):Re search engines becoming less useful: a lot of folks feel that way, and there's good reason to believe it's only going to get worse. This article has done the rounds on popular link aggregators: https://docs.sendwithses.com/random-stuff/the-internet-is-an-seo-landfill
OTOH ChatGPT et al. keep getting better at doing what I used to use search engines for. E.g. I can paste in some convoluted regex I find in my codebase and it will do a fantastic job of explaining it in plain language. I haven't tried asking ChatGPT about Wasm-related topics. If you're interested in trying it instead of Google next time, I'd love to know how your experience compares!
Piotr Sarnacki (Oct 13 2024 at 15:49):@Joel Dice I've read through the docs you linked and some other resources I could find. You mentioned that the blocker is compiling Starling Monkey to a shared library, but I'm not sure if you mean that compiling to shared libraries is a blocker or that compiling Starling Monkey to a shared library is a blocker. I assume the former, but not sure.
Do you know if there are any resources outlining what is needed to do so? It's extremely hard for me to find anything concrete. I mean, it doesn't have to be necessarily in context of StarlingMonkey/SpiderMonkey, I would like to first experiment with smaller examples. Then there is also componentize-js changes, but I guess figuring out this part will be easier if I know exactly how it should work.
Joel Dice (Oct 13 2024 at 20:22):You mentioned that the blocker is compiling Starling Monkey to a shared library, but I'm not sure if you mean that compiling to shared libraries is a blocker or that compiling Starling Monkey to a shared library is a blocker.
The latter. DynamicLinking.md describes the convention for building and linking Wasm shared libraries, and Emscripten has been using that for many years. We've been using the same convention to link arbitrary numbers of shared libraries together using wasm-tools component link, and componentize-py relies on that (plus dlopen emulation) to support Python native extensions as .so files.
In fact, if you use wasm-tools print to look at a component built by componentize-py, you'll see it is composed of several .so files, including libc.so, libc++.so, libpython312.so, etc. -- all of which follow the DynamicLinking.md convention. There's no reason why componentize-js could not do the same thing -- it just hasn't been a priority yet.
Last updated: Nov 22 2024 at 17:03 UTC