Javascript:SpiderMonkey:OdinMonkey

Goal

Provide an optimized implementation of the (co-evolvoing) asm.js spec which achieves near-native performance (within 2x of -O2) on JS generated from C/C++ (with the pilot code generator being Emscripten).

Status

The project is currently in a research phase with the major evaluation criteria being to get several large-scale Emscripten apps (BananaBread, zlib, and Bullet) running and showing the target performance. At this point, we can make the informed decision to transition to an engineering project.

The code is currently available as a patch queue based on mozilla inbound. Unit tests (which can serve as example code) are in js/src/jit-tests/tests/asm.js/.

The entire asm.js language has been implemented. Most of the (smaller) Emscripten benchmarks are running and coming in under 2x. The three big benchmarks are in: zlib is right at 2x, Bullet is more like 2.3x (we think it needs float32), BananaBread doesn't have a comparison w/ native yet but we are seeing a 4x speedup over general IonMonkey/V8.

Remaining experimental work:

• Get BananaBread working in the browser (with Alon's sweet deterministic harness).

Tasks before initial landing

• Tier 1 platform support (remaining):
  • x64 (Windows)
  • x86 (Windows, Unix), using segment registers
  • ARM
• Safety
  • Add slow-script and stack-overflow checks (to be removed later).
  • Fix that pesky x64 call-out-of-range TODO by using a single linear allocation.
• Quality
  • Fuzz (with decoders mutation-based fuzzer based on existing asm.js programs)
• Engine integration:
  • Error.stack should include asm.js frames
  • SPS's profiler stack should work as well
• Audit Odin code for OOM-safety.
• Final polish on error messages
• Unbreak IonSpew

Further work (after initial landing)

• Optimize asm.js-to-Ion transition with custom-generated exit stub
• Add DataView to asm.js to allow us to avoid masking on loads/stores
  • Measure how much it'll win us (so far, 20% on zlib)
  • Signal-handler support
  • Investigate this 32-bit/64-bit register slicing issue
  • Investigate using fs/gs on x64
• Avoid slow-script and stack overflow checks with signal handler support
• Add a float32 type to asm.js to allow 32-bit float arithmetic
  • Measure how much it'll win us
  • Add float32 versions of all the IM float64 ops.
• Optimize idiv (using signal handler for FP exception)
• Optimize double-to-int conversion (using signal handler for FP exception)
• FunctionBlob (TODO: link to proposal)
  • Efficient transfer between workers
  • Efficient IndexedDB serialization/deserialization
• Full GVN/range analysis support for all the new asm.js IM MIR nodes
• ToInt shouldn't generate so much code

General IonMonkey optimizations

• Optimize control flow to minimize jumping (we tend to a lot worse than GCC here since we don't even try to optimize this)
  • Rearrange loops to put the condition at the end
  • Fold jump-to-jump into single jump
  • Reorder blocks to replace jumps with fall-through.
• Use 32-bit register encoding on x64 for when the MIRType is int32
• Use pc-relative constant double loads instead of trying to use immediates (GCC does, need to measure perf)