Explain the conection of GC and DOM-Access in laymen's terms

[NeverGivinUp]

The web.md as well as #1079 state that an implementation of garbage collection is necessary, before WASM code can access and manipulate the DOM and CSS without calling Javascript. Even if using languages like C and Rust, that handle their own memory. I'd feel better oriented, if the connection was more explicit.

[seanwestfall]

I would also like to second this as a legitimate question, though not necessarily in laymen terms.

Why is DOM access and Garbage Collection consider the same issue? @rossberg is I believe assigned #1079. I was actually planning to ask this during the April 3 meeting but I'm not sure if I want to use this question to take up meeting time if it can better be answered here.

[rossberg]

The main reason is that direct access to the DOM requires the ability to pass references to DOM/JS objects through Wasm. Consequently, when GC happens for JavaScript, the collector must be able to find and update such references on the live Wasm stack, in Wasm globals, or in other places controlled by the Wasm engine. Hence the engine effectively needs to support GC in some form.

However, the new proposal for reference types that we split off from the GC proposal tries to give a more nuanced answer to that. It introduces reference types without any functionality for allocating anything within Wasm itself. In an embedding where host references are garbage-collected that still requires a Wasm implementation to understand GC. But in other embeddings it does not need to.

[trusktr]

It seems that if we're going to wait for DOM GC to signal to Wasm when to free things on the Wasm side, then we're going to start having jank (f.e. pauses during graphical rendering every second when GC runs), which is the very thing I am hoping to avoid by using Wasm.

Does my fear stand? Or will this not be a problem in Wasm?

It just seems that if I have a Wasm app (with possibly small to no performance gains against well-written JS), which will now be tied to the same GC cycles as the DOM, then we won't be gaining much, and it may be easier to just write JS in most cases. Is my sentiment wrong here?

[Macil]

WebAssembly in the main thread already has to be paused while the main thread does garbage collection because they're in the same thread. (You can run WebAssembly in a web worker, but then just like Javascript in a web worker, it can't get direct DOM access. You could have JS or WASM in a web worker do the heavy lifting and have it talk to JS or WASM in the main thread which then does the DOM operations.)

Currently, WebAssembly instances can't directly reference DOM nodes or anything garbage collectable. When WebAssembly gets the ability to reference garbage collectable things such as DOM nodes, then there must be a way for the garbage collector to peek into a WebAssembly instance to see if it's referencing an object to tell if the object is safe to garbage collect. (WebAssembly instances will have special tables for storing references separate from their main memory; the garbage collector won't have to scan through the instance's whole memory to look for references.)

[trusktr]

Cool. Thanks for explaining that.

If we are, for example, wishing to run a 3D + Physics engine in Wasm, then render to a <canvas>, how could this feature impact that? Seems like we'd want to run that 3D+Physics engine in a thread, and in that case this GC feature may not matter (because no access to DOM in the thread anyways)?

[Macil]

Canvas is a DOM API (though there is special support for accessing canvases inside of a web worker; browser support isn't very wide yet), and if you want to read user inputs, those are also DOM APIs. If there's nothing much else going on in the webpage, and the user is only interacting with the thing in the canvas, then there's not much benefit to putting the canvas-handling code off of the main thread. If the only code running on the page is your physics simulation in WASM and a little bit of code to read user inputs and update the canvas, then garbage collections will be infrequent and tiny. The time a garbage collection run takes is generally proportional to the number of live GC objects, and very few would be needed for this. (A WASM instance's entire flat memory is a single GC object.)