Hacker News Reader

Comment by torginus | Hacker News Reader

Genuine question about GC'd languages on Wasm - how does the GC run?

When running a GC language in its own runtime, usually there is at least 1 GC thread, that runs concurrently with the app code and pauses/preempts the main thread.

Afaik, in WASM, your application only has CPU time when you are inside a WASM function and threading is incredibly hacky and may be disabled due to security reasons related to side-channel attacks (read up on `SharedArrayBuffer` and cross-origin site isolation).

View on HN

Garbage collection isn't generally something that happens periodically as it isn't needed until you get a bunch of new allocations and classically did not happen on some background thread as that's both extremely difficult to pull off and requires threading support in the first place. The simpler way to think about garbage collection is you establish a heap, set a size, and when you run out of space in that heap you run a garbage collection pass during the memory allocation that failed. If you fail to free enough memory, you either kill the program or request a larger heap.

This is the way it is described in the GC Handbook as well.

  New(): 
    ref <- allocate()
    if ref = null
      collect()
      ref <- allocate()
      if ref = null
        error "Out of memory"
    return ref

Currently there is no official support for GC in WASM. So currently any compilation of GC'd language into WASM must provide it's own GC which will be part of the WASM binary.

WASM is a virtual processor spec. There's no GC support in X64 assembly nor ARM assembly and there's no GC support in Web Assembly because they are all assembly languages. You get a hunk of memory, you manage it however you want. If you want GC you you implement GC the same way the JVM implements GC on various processors.

It runs alongside the application, basically you're back to using RC as GC algorithm or only when memory needs demand a full GC.

Virgil compiles its tracing semi-space collector into the application. It's the same code as the native GC. The major difference is that the call stack is not visible, so the compiler must spill all live references on the stack into a shadow stack in memory. That last part was the trickiest and most inefficient part of porting.

Yeah, but it doesn't run in parallel, does it?

No, you need an additional safepoint mechanism to do that.

Thanks!

Reference Counting, ok!

Reply on news.ycombinator.com