So I've been working on my minimal druntime for wasm, and discovered that LLVM actually uses a shadow stack for wasm, not the native non-addressable wasm stack. Which means that it's possible to scan the (shadow) stack for GC roots. Which means, in theory, that the full druntime *could* be ported to wasm, GC and all.

Of course, GC parameters would have to be tweaked in order to fit the memory constraints of your typical wasm environment. And probably lots of performance tweaking would be needed. But it'd work.

Which also means that we don't have to wait for WasmGC support to land in llvm before we can target wasm. In an ideal world the host GC would take care of providing GC services, but even today, what we have ought to be enough to port the current D GC to wasm(!).

//

Porting the entirety of druntime to wasm is kinda way out of my scope right now. I'll probably continue working on gradually expanding my current minimal druntime to cover more and more of the language. It might be a good opportunity to experiment with alternative GC schemes too. I've started with a dumb bump-the-pointer allocator, and planning to gradually expand it to full GC in the not-so-near future.  Maybe I'll experiment with write barriers and incremental GCs as well, once I get to that point...


T

-- 
Tell me and I forget. Teach me and I remember. Involve me and I understand. -- Benjamin Franklin

On Wednesday, 7 February 2024 at 03:52:15 UTC, H. S. Teoh wrote:

> Porting the entirety of druntime to wasm is kinda way out of my scope right now. I'll probably continue working on gradually expanding my current minimal druntime to cover more and more of the language.

Maybe this will help: https://github.com/dlang/dmd/pull/15887#issuecomment-1925823060

This patch highlights minimal number of the druntime pieces that need to be changed for the another platform support

On Wednesday, 7 February 2024 at 03:52:15 UTC, H. S. Teoh wrote:
> So I've been working on my minimal druntime for wasm, and discovered that LLVM actually uses a shadow stack for wasm, not the native non-addressable wasm stack.

It does for debug, but then the optimisations push a lot of that to the wasm stack, see mem2reg step in llvm.

A possibility is to run the spill-pointers pass of binaryen, that should hoist the pointers back out to the shadow stack. With some perf hit of course.