I'm not sure what you mean by that. Is there some limitation inherent to WebAssembly that makes implementing garbage collection particularly difficult?
For what it's worth, here's Lua (which implements a garbage collector in its runtime) in WebAssembly: https://github.com/vvanders/wasm_lua
Code:
print(_VERSION)
local a = setmetatable({}, {__mode = 'v'})
local b = setmetatable({}, {__gc = function(x) print("Deleting: " .. tostring(x)) end})
a[1] = b
a[2] = 2
print(table.unpack(a))
print(collectgarbage'count')
b = nil
collectgarbage()
print(table.unpack(a))
Lua 5.3
table: 0x50a748 2
21.4033203125
Deleting: table: 0x50a748
nil 2
Perhaps http://www.lua.org/demo.html could be replaced with that for users who have JS enabled.
Again - just wow, that's really nice, Lua in a browser.
Yes, in that you'd have to implement the GC inside the wasm module itself (as in your example). In contrast to other languages, Lua is very lightweight. Many GCs are non-trivial.
Moreover, proper GC support is a piece of the puzzle for the wasm/JS/DOM interop story to get better.
That is essentially the same problem people implementing garbage collectors on real machines are facing. You have some memory and you have to implement the algorithms and data structures necessary to allocate and free it as necessary.
> Lua is very lightweight. Many GCs are non-trivial.
Yes, but don't confuse the problem of implementing a garbage collector with the problem of implementing a system that can support a garbage collector. The former may be non-trivial, while the latter only supposes an architecture where you can arbitrarily manage memory "manually". From what I understand, you just hand WASM an array of memory and it can do whatever it wants with it, since it's a linear bounded automaton.
> Moreover, proper GC support is a piece of the puzzle for the wasm/JS/DOM interop story to get better.
The link seems to be addressing the use of VM-managed GC objects within WASM programs. That would certainly a nice feature, especially when it comes to interoperability with JS, but the lack of it is not a showstopper for implementing your own garbage collector as it has always been done.
In most cases it isn't non-trivial, and that's further compounded by the fact that the GC currently has to be part of the module payload at the moment.
If we're talking strictly implementation difficulty, then interop with VM-managed GC objects may in fact be more difficult; I'm certainly not an expert so I couldn't tell you.
>... but the lack of it is not a showstopper for implementing your own garbage collector as it has always been done.
Per the very first sentence of mine you quoted, I never said it was. It certainly is likely to be far from practical, however.
Also I suggest reading the sibling comment that Steve Klabnik replied with prior. The wasm host bindings proposal is now separate from the GC proposal.
I commented with a link elsewhere, but it seems that people have found a way around that!
https://news.ycombinator.com/item?id=15694292
https://news.ycombinator.com/item?id=15694289
I didn't see those, thanks. That's good news. Hopefully host bindings land sooner now than they otherwise would have if tied to the GC proposal.
The wasm32-unknown-unknown LLVM backend target for Rust is also quite exciting. I say this after having just spent a minor eternity compiling the Emscripten toolchain. :)