[azakai]

asm.js is a subset of JavaScript, and to be easy to optimize, it removes most of the dynamic stuff from JS and leaves a simple, low-level dialect that is basically equivalent to LLVM IR or to C.

You can compile many things to C and LLVM IR, like C++, C#, and so forth. You can compile the VMs of dynamic languages like Python, Lua and Ruby, but compiling them directly would be inefficient - you'd need type checks all over the place. You need a custom VM to be fast on those.

asm.js can run Lua at close to the speed of the normal Lua VM running natively, so this approach is very feasible. But, for JavaScript itself, it probably doesn't make sense, the current VMs are the best that can be done.

However, a subset of TypeScript - without classes, without weird prototype things, just arrays and numbers and computation on those - could be compiled to asm.js. That might be an interesting project to try out.

[fractalsea]

OK, so are you saying that compiling the language's runtime environment, including the GC, to asm.js would not be efficient enough? That makes sense.

I guess I was hoping that there may be some way to compile the runtime such that the GC wouldn't need to be compiled, and the GC of whatever is interpreting the asm.js code (e.g. SpiderMonkey) could be used instead.

[DougBTX]

That's roughly what happens when TypeScript gets compiled to JavaScript, it can use the browser's GC. asm.js is used to avoid the browser's GC, either when the original code doesn't need a GC since it uses manual memory management, or it uses a different type of GC from the browser and wants to use that instead (which is effectively the same thing).