41–47 of 47 posts
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.
Earlier quoted context omitted.
I thought you didn't have raw stack access in wasm, making efficient concurrent GCs impossible practically in native wasm. Hence the GC work to give a higher level API that can more easily be sandboxed.
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 thei…
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.
Earlier quoted context omitted.
This is analogous to different UNIX programs communicating with shmget and a synchronization primitive. It's still a multiprocess model.
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 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.
I thought you didn't have raw stack access in wasm, making efficient concurrent GCs impossible practically in native wasm. Hence the GC work to give a higher level API that can more easily be sandboxed.