I'm extremely bullish about Rust riding wasm the same way Go rode the container space. This kind of work is exactly why I feel that way. It's uniquely positioned to take advantage of the benefits of wasm; building faster, safer applications on the browser.
I look forward to the day when the web is Rust, although I guess if you're using Firefox, that's already partly true. :)
The ultimate test would be to see if it is possible to implement an efficient concurrent GC in Rust+WASM. This might require memory fence instructions in WASM.
It's worth noting that you can, and in general do, create your own stack in the wasm memory space. WebAssembly's native stack can only handle 32 and 64 bit integers and floats, so local variables are more like registers
Virtualization technology is quite mature now, and allows running low-level code (that can access the stack) with safety. Servers run this type of code all the time!
Why would we throw away these achievements, and turn WASM (with its potentially simple instruction set) into a complicated monster, that's prone to security problems through its complexity alone?
Also, language designers do not want a GC embedded in their assembly language; they want to implement it themselves, using their own constraints.
> Why would we throw away these achievements, and turn WASM (with its potentially simple instruction set) into a complicated monster, that's prone to security problems through its complexity alone?
Because sandboxing in process is difficult otherwise. You can't allow the user to control code pointers, but for performance reasons you both need to have the raw pointers on the stack, and need to have semi privileged code in the same process just a function call away. Throwing everything into the process/hardware virtualization models doesn't fit this use case very well. It's why the VM in browsers carefully controls code pointers and is already pulled out to a semi sandboxed process.
And I'll grant you that language implementors want raw stack access to implement their own performant GC; that just doesn't exist yet in wasm.
> Virtualization technology is quite mature now, and allows running low-level code (that can access the stack) with safety. Servers run this type of code all the time!
Except that "low-level code" is not portable. Which is why we have wasm instead of NaCl.
Incidentally, stack isn't the interesting part. For a good GC on register-rich architectures like AArch64 you really want register roots, which is hard to abstract over portably.
> Also, language designers do not want a GC embedded in their assembly language; they want to implement it themselves, using their own constraints.
I was a language designer in a former life, and I very much want a GC in Web Assembly. Web Assembly doesn't exist in a vacuum: it needs to interact with the DOM for I/O, in much the same way as a Windows program needs to interact with COM to do lots of things. Having two tracing garbage collectors that trace different objects is a nightmare, so I want the same GC that the DOM uses. That is exactly what the wasm GC proposal is.
Can you clarify what you mean by "virtualization technology". It's a pretty broad term ranging from hardware assisted system virtualization to application virtualization to containerization. All of these types are run on servers all the time but each has very different performance and security characteristics.
IBM did a JVM (J9?) that used stack checkpointing and interrupts for some of its GC tasks. GC pauses were nearly instantaneous instead of instantaneous, because all threads have to run to a safe point before the mark phase happens.
Various real time systems have used amortization strategies to spread out GC overhead (eg, each memory allocation will GC up to 10 objects).
That's sort of orthogonal to what I'm talking about. The issue is that wasm doesn't yet give you the tools to implement those techniques (namely the ability to do brain surgery on a running stack).
If it sits on WebWorkers like proposed then no, that won't be possible. WebWorkers are really more multi-process with a somewhat bad IPC mechanism than multi-threading.
Nice, was just reading your issue [0]. I spent a bit of time the other day thinking how I could implement these thread ops on the JVM (JVM rambling henceforth, skip if not curious)...
First, my project's output requires no runtime/dependencies, so I am restricted to JVM libs only. Memory is implemented as a ByteBuffer which does not have atomic access. I didn't quite understand the threads spec wrt data init on mem so I'll have to get clarification there (lock all mem? just go and pray?). The implementation will create four synthetic methods in the class: lock, unlock, wait, and wake. The class will have a field that is ConcurrentMap<Integer, int[]> where the key is the mem offset being locked, and the value is an array of mutable int refs size 2, the first being lock ref count and the second being wait ref count. Imports of shared memory pass that around along w/ the ByteBuffer.
Lock will create/incr ref count and secure the lock via monitorenter on the int array (or fail if ref > 0 when just a try). Unlock will monitorexit and decr the count (removing from map if both ref counts are 0). All ops are done between this lock/unlock. Wait/wake is via wait/notify on the JVM, but JVM has no construct to say how many or if any threads were woken up on notify, so I have to keep the wait count. Incr/decr on the ref and wait vs notify (in a loop if > 1) is done as expected using wait() and notify() on the array itself. The lock, unlock, wait, and notify are done w/in concurrent map's compute making them atomic. Lock/wait lazily create the refs in the map. Unlock/notify, upon reaching 0 for both refs at the end, clear the refs out of the map.
I have looked into existing JVM constructs and this seems to be the best way (I wish I could use Guava's Striped or the like, but I have no dependency/runtime requirement on outputted class files). Countdown latches, other locks, conditions, etc were all runtime overkill. I could have better performance than a boxed-int map with some extra code but wanted to keep it simple. Granted this is all pie-in-the-sky thinking, the impl will change it for sure.
I am afraid to start an implementation because the proposal isn't further along yet (I really need some test cases in the suite to make me feel better).
The article title is misleading. Wasm will not support multithreading, rather it'll be multiprocess via web workers and shared arrays for communication. It's not a single address space - code or data.
WebAssembly modules today are optionally associated with at most one instance of “linear memory”. In non-wasm parlance, you can put a stick of RAM into a wasm module. This WebAssembly.Memory is today always backed by an ArrayBuffer, but you’ll soon be able to flag a memory as “shared” which means it’s backed by SharedArrayBuffer instead. This subsequently means that the structured clone of a WebAssembly.Memory backed by a SharedArrayBuffer will refer to the same memory!
At that point, the distinction between threads and processes gets really muddy even when you're not using wasm. clone(2) is just a superset of fork(2) that lets you decide whether to share memory or not (among other resources).
I still think one could use a stackless clone(2) to get rid of the TLB flush when using threaded open(2). It would need to live without using the stack inside the clone however, and that's rather ugly to program.
Technically, you are right, but if multiple processes use the same shared memory is there a real, meaningful difference? You can do efficient, parallel computation in a browser, does it really matter how it is executed under the hood?
If the very first thread that's created has to do some bookkeeping that the other created threads rely on, what happens if you create a second thread at the same time as the first one? Or in other words, what happens if you don't instantiate the module on the browser's main thread at all, but instead just spin up 2 web workers that each instantiate the module? Whichever starts first will be thread 0, but what's to stop the other worker from entering its `start` function while the first worker is still busy initializing memory?
Nice article. Now I know why the ManualResetEventSlim didn't work in c# Blazor. I wasn't aware that multi-threading in wasm was work in progress.
The demo doesn't work on the standard latest firefox yet unfortunately (ver 63.0). Error: "this browser does not have SharedArrayBuffer support enabled". I guess this is a nightly firefox build thing.
> this browser does not have SharedArrayBuffer support enabled
It was disabled for Spectre safety reasons, but it can be re-enabled by navigating to "about:config", searching for "javascript.options.shared_memory" and toggling it to enabled. (But it was obviously disabled for good reason, so might want to enable it temporarily)
Thanks! That fixed that problem. Except now I get "this browser does not support passive wasm memory". There aren't any obvious javascript.options.* options for that.
Oh dear sorry about this, it's a little too non-obvious how to see the demo! I've [pushed a small commit](https://github.com/rustwasm/wasm-bindgen/commit/f016ae5846bf...) to update the demo to include information about browser requirements. Today this demo requires Firefox Nightly (64) and requires the `javascript.options.shared_memory` feature to be enabled. Other browsers will likely soon be able to run the demo as well!
It's definitely worth looking into. Although the authors of the library keep reminding the reader that blazor is not production ready I have found that it does everything I need it to. I found that it either works or doesn't at all if there is an unhandled exception in your code to you try to do something that is not supported. However, I haven't found the behavior to be non-deterministic (by that I mean flaky). I guess they may want to change the API before release. What is amazing is the ability to reference .net standard libraries.
> must be really telling something positive about this language and its community.
It's because it's the new shiny thing. This basically used to be a ruby on rails post-it board, then C# for a while, then Java when Java 8 Streams were announced, then Go, etc.
I am not saying it's a bad thing -- in fact I can't wait to go through that "write an OS in Rust" blog that was posted here earlier -- but no I don't think it's telling of anything quite yet.
It's not just because it's shiny. Rust happens to (a) be a great fit for the parts of WebAssembly that have been implemented so far (partly because it doesn't need GC), and (b) have done a really good job of building WebAssembly tooling with nicer ergonomics than other languages.
Even though the DOM story hasn't been figured out, firefox has recently done work to make WASM <-> JS calls performant. So now things like Yew will probably be usable from a performance standpoint[0]. But apart from the DOM, it's good for CPU intensive things[1].
As a child raised on 80s 8-bit computers, and a fan of emulation, I love what WASM does for in-browser emulators. You can run an enormous amount of Apple II, Commodore 64, etc. software on archive.org, all compiled using emscripten.
I regularly hit a search [1] to pick up Rust related stories. Most Rust-related articles don't make the front page and most see no comment activity at all.
Lately the WASM+Rust stories see a lot of activity. Also, some 'I learned Rust and this is what I think about it' type blog posts attract comments. The rest do not. 10 hours ago: "Ask HN: Rust, anyone?" asking who is using Rust in production. No replies.
I look forward to the day when the web is Rust, although I guess if you're using Firefox, that's already partly true. :)