2 ms·
"VM-atop-asm.js-atop-the-JavaScript-engine would be the thing doing the GC" "much of the speedup also comes from the lack of dynamicity, too." In the language
by niggler 14y ago
"VM-atop-asm.js-atop-the-JavaScript-engine would be the thing doing the GC"
"much of the speedup also comes from the lack of dynamicity, too."
In the language, JS gives you no control over its underlying GC. Every single assumption that asm.js leverages depends on the determinism, and introducing a GC into the mix really messes with AOT optimizations
- glhaynes 14y agoBut the JavaScript engine's GC isn't applicable here, is it? Because everything from the asm.js layer up is using a privately-managed heap implemented as a single (?) JavaScript typed array (ArrayBuffer) with no JavaScript-engine-level visibility of the distinct asm.js-layer values stored in it. Edit: perhaps the thing I'm missing is that the discussion is about direct translation of CLR IL/JVM bytecodes into asm.js without any vestige of the CLR/JVM still running alongside. I was merely thinking of compiling the CLR or JVM to asm.js then hosting unmodified CLR IL/JVM bytecode atop that. Which seems feasible, though not as performant as a VM-less translation which I agree doesn't seem possible.