garbage collection

[Mitch VanDuyn]

thinking about how to use emscriptem to run Crystal (language) in the browser.  Because the code will interact heavily with the DOM and JS libraries (like React.js) I do not want to run in the WASM, but rather in the JS environment.

Crystal generates LLVM so that is not a problem.

The problem is that Crystal depends on a garbage collector.

My question is if I generate .js (instead of wasm - see https://emscripten.org/docs/getting_started/FAQ.html#what-is-no-webassembly-support-found-build-with-s-wasm-0-to-target-javascript-instead-or-no-native-wasm-support-detected) can I let the memory allocated be collected by the normal JS garbage collector?

[Floh]

AFAIK all Javascript-generating output options in Emscripten (even before asm.js) use a single JS array to represent the entire C heap, so there's no 1:1 relation between an heap allocation and a Javascript object (which could then be garbage-collected), instead there's only one big JS heap object which must be alive for the entire application live time.

Also the emscripten-generated code has no concept of garbage-collectible JS objects at all, instead "everything is a number" (although WASM will get this eventually, which allows to pass JS object references into and out of WASM: https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md)

Until this extension happens, interacting with Javascript APIs or the DOM requires a JS shim which translates JS object references into a plain number "id", or a number-id back into a JS object reference (usually through an dictionary on the JS side with the number as key, and the JS object reference as value).

TL;DR: AFAIK you probably won't get much of an advantage choosing Javascript over WASM output via emscripten for interacting with the DOM and JS APIs, because both use the same flat memory model in a single JS array, and everything on the emscripten side is a number, there are no JS objects.

Cheers,

-Floh.