[OT] web assembly memory model

[H. S. Teoh]

On Mon, Jan 05, 2026 at 01:48:25PM +1300, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> On 05/01/2026 1:33 PM, Walter Bright wrote:
> > Thanks for the explanation. What it suggest to me is that a subset
> > of D will work perfectly fine with WASM.
> 
> Yes it should do, but it'll be limited enough that people will get
> annoyed with it rather fast, at the very least I would.
> 
> Not worth my time building up a new backend and a new runtime for it.
> 
> The whole time it'll be nope can't do that, or that or that... Ugh me
> no like.

In the past I've managed to get a rudimentary (highly-hacked) druntime
running in WASM, with bare-minimum support for module ctors and JS
interface.  It's quite comfortable to use, except for memory allocation.

Problem is, either you have to port the entire GC implementation to
WASM, which will take up a LOT of code (i.e., slow loading of your
project over the web), and require gobs of memory to run (your memory
requirements will go way up, even for the simplest of modules), or you
have to live with completely no GC, or some hackish in-between.  For
things like frame-based animated games, you could get away with
per-frame allocation, i.e., allocate everything statically before the
main loop, then during the main loop all allocations only last until the
end of the frame, after that it's thrown away.  While it will work, it
lacks the comfort of programming with full GC support.  You couldn't
just use standard D features like delegates and closures without
worrying about lifetime issues.  Things like threading and other
advanced features will of course be very limited as well.

I haven't had the motivation to actually port the GC to WASM, because it
adds so much code that it becomes a bigger project than the target app
itself. I ended up going back to JS for web projects just to avoid
having to grapple with these issues.  Dreamed about writing a D to JS
translator, actually, just haven't gotten around to it yet. :-P

WASM GC is a thing, but it requires treating GC references as separate
types from normal pointers, which D's memory model just doesn't fit in
well with.  Host-managed GC'd memory is also treated differently from
linear memory; the layout of the object must be known to the host so
generic pointers and unions are unsupported.  It also requires LLVM
support if you're using LDC, but AFAIK LLVM doesn't have full support
for WASM GC yet.  IOW, WASM GC imposes restrictions that are
incompatible with D's memory model, so it will be very hard to work with
it.  The only alternative for full GC support is to port the GC itself
into WASM.  As I said, it greatly increases the payload size and memory
requirements, and also won't be as efficient as the host browser's GC.
All in all, a suboptimal situation.


T

-- 
First Rule of History: History doesn't repeat itself -- historians merely repeat each other.