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.
Hence the GC work to give a higher level API that can more easily be sandboxed.