Hacker News Reader

Comment by azakai | Hacker News Reader

TypeScript is garbage collected, like JavaScript, while WebAssembly is not. So directly compiling TypeScript to WebAssembly isn't possible, without also compiling in a userspace GC implementation.

I'm not sure what Thinscript does for this. edit: README says nothing is deleted, so I guess that each new() allocates but nothing is freed?

View on HN

I'm planning on experimenting with either pure reference counting (Swift), reference counting + cycle collection (Python), or garbage collection. I'd love to hear about what people are doing for emscripten actually. I've read that Unity uses IL2CPP which uses the Boehm GC but I couldn't find anywhere that described how that actually works in emscripten. Local variables correspond to "registers" in machine code, but how does the garbage collector read them so it can scan them during a collection?

Yeah, a bunch of projects use Boehm (or their own GC, like the Lua VM). For large projects the extra size of including a GC implementation isn't so bad (but for small ones it can be). And it can be fairly fast.

A problem is that you can't have GC cycles with the outside world, so you can't interact with the DOM in a normal way. In particular, your objects can't be automatically GC'd if they can be held on to by anything outside of the compiled linear memory. That's why emscripten's C++ <-> JS binding tool has a .destroy() method on each wrapped C++ object, as they need to be manually destroyed by the user.

For local variables, they aren't scannable by themselves. You need to emit special inline code that writes them to linear memory. In C++, you can do this with an RAII class for a reference, for example.

One trick you can use (which Chromium+Oilpan uses) is to only GC in between turns of the event loop. In that case, your set of roots is exactly equal to the accessible global variables plus everything accessible from the DOM (including event handlers). In particular, nothing is on the stack, so there is no need to introspect stack frames.

I considered that but I'm worried that won't work with WebAssembly because it's a more memory-constrained environment. Your app may generate a ton of data in a frame and run off the end of the address space. I guess I'm probably just thinking back to asm.js where you sometimes only have 256mb to work with. I'll try this first at least since it makes stuff easier.

Just go with pure reference counting. It'll be faster and easier.

That's a really clever idea. Thanks for sharing.

Reply on news.ycombinator.com