This is the tracking bug for landing OdinMonkey. (OdinMonkey is the project name for SpiderMonkey's optimizing compiler for asm.js (http://asmjs.org), built on top of the IonMonkey backend.) Current results on large Emscripten codebases are as follows, reported as factor slowdown compared to gcc -O2 (so 1.0 would mean "same speed"): odin (now) odin (next) sm v8 skinning 2.80 2.46 12.90 59.35 zlib 2.02 1.61 5.15 5.95 bullet 2.16 1.79 12.31 9.30 "odin (now)" is what you get on trunk. "odin (next)" is after we remove some dynamic checks by using signal handlers. BananaBread is also compiling and running asm.js and showing a nice speedup over SM/V8 (2-4x) when running headless, but we'll need to get float32 support before we can do an apples-to-apples comparison vs. C++. There are several further optimizations we know of for which we don't have measurements yet: https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey#Further_work_.28after_initial_landing.29 but we feel that the current results are convincing enough to land now and continue optimizing afterwards. The code is currently in a user repo ('hg diff -r trunk' to see the diff): http://hg.mozilla.org/users/lwagner_mozilla.com/odinmonkey At a high level, the interaction with the VM is as follows (see AsmJS.h): 1. After parsing (before emitting) a function, the frontend calls CompileAsmJS. CompileAsmJS performs type checking (a simple traversal of the parse tree) and simultaneously emits fully type-specialized IonMonkey MIR nodes. 2. If type checking succeeds, the entire asm.js module (collection of functions) is compiled by the IonMonkey backend and attached to the script. (Later, we'll do this in parallel and block in step 5.) 3. The frontend emits the script as bytecode with the first op being JSOP_LINKASMJS which, when executed, performs the dynamic validation of arguments as defined in the asm.js spec. 4. If the dynamic validation succeeds, the asm.js module's exports are returned as native functions that trampoline into the compiled code. (No further invalidation/deoptimization can occur.) This bug can be used for reviewing the code for landing. Before that, though, there are several remaining work items which I'll file as blocking this bug.

Desktop x86/x64 is in a good initial state: we're continuing to see a nice 2-3x speedup on large JS-bound codebases and we've gotten a significant amount of testing: the Emscripten/LLVM test-suite, a C fuzzer feeding into Emscripten into Odin, and decoder's mutation-based fuzzer running on existing asm.js codes. Based on this, I've seen consensus that it is a good idea to land desktop-Odin support now and continue work incrementally on trunk. In particular, ARM (bug 840285) and some big load-time improvements for huge codes (bug 850070 and bug 851421) are coming soon. https://hg.mozilla.org/integration/mozilla-inbound/rev/b3d85b68449d Since we expect asm.js to change (in response to feedback from other JS engine teams and our own future work), I've put Odin behind the pref javascript.options.experimental_asmjs. Following current practices for other new features in FF, this pref defaults to "on" on nightly/aurora and "off" on beta/release. We can rename it to just "asmjs" when we've reached a fixed point on asm.js (v.1). I'll leave this bug open until ARM is done and then we can move on to a new [meta] bug for future work.

We never fixed bug 842728. Does that need to block something?

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #2) > We never fixed bug 842728. Does that need to block something? It would/will help with testing, but it doesn't block anything.

js/src/ion/RegisterSets.h:461:2: error: #error "Bad architecture" This broke powerpc.

Unfortunately, I've had to temporarily disable OdinMonkey on OSX: https://hg.mozilla.org/mozilla-central/rev/aa0fc30a3c2e Bug 851964 filed to reenable.