Hacker News Reader

Comment by Humphrey | Hacker News Reader

How does this handle garage collection? I believe Webassembly doesn't yet support GC so, is this manually compiling it's own GC into it?

View on HN

They are compiling libmono (an embeddable .net runtime) to wasm. That runtime has its own GC.

Mono already supports embedding the runtime with the application. So they just used that feature here. Also available is the mono interpreter which does it's own garbage collection.

It’s more complex than that, as there’s tons of academic work essentially proving it’s impossible to chain two independent garbage collectors and not end up with stuck uncollectable memory (I apologize, this isn’t my field, I’ve skimmed the work but not retained the citations, and I realize how counter-intuitive that result is... nobody wants to think its true, so it keeps getting more academics thrown at it, without changing the results).

My assumption is that at the moment they are just accepting that some uncollectable memory will happen in the short term and eventually the WebAssembly working group will expose the underlying garbage collector and everything will get better. Early days kind of issue for now.

Xamarin.Android begs to differ. It provides full integration and all we use from Dalvik are gc handles and explicit GC control.

Full Disclosure: I work at MS and I am one of the original designers of it.

In the WASM case it's trivial to show how this is the case at the moment: WASM just has a large ArrayBuffer, which the JS GC will hold on to all of, regardless of how much the GC in WASM deallocates.

Yes, I think that's part of mscorlib.dll.

The GC lives in the runtime, IIRC every runtime's GC is native code and most of them have their own. If memory serves most of the official Microsoft runtimes share the same GC implementation (it's open-sourced in CoreCLR), but I'm not 100% sure on that. Mono has two GCs, Boehm and SGen, and the latter is custom.

Reply on news.ycombinator.com