The default bug view has changed. See this FAQ.

Land OdinMonkey (asm.js optimizing compiler)

RESOLVED FIXED in mozilla22

Status

()

Core
JavaScript Engine
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: luke, Assigned: luke)

Tracking

(Depends on: 1 bug)

unspecified
mozilla22
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

4 years ago
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.
(Assignee)

Updated

4 years ago
Depends on: 840280, 840281, 840285, 840283, 840284

Updated

4 years ago
Depends on: 850052
(Assignee)

Comment 1

4 years ago
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?
(Assignee)

Comment 3

4 years ago
(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.
Depends on: 851787
https://hg.mozilla.org/mozilla-central/rev/b3d85b68449d
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22

Updated

4 years ago
Blocks: 851880
(Assignee)

Comment 6

4 years ago
Unfortunately, I've had to temporarily disable OdinMonkey on OSX:
https://hg.mozilla.org/mozilla-central/rev/aa0fc30a3c2e

Bug 851964 filed to reenable.
Depends on: 852107

Updated

4 years ago
Depends on: 852356
Blocks: 868184
Depends on: 913876

Updated

3 years ago
Depends on: 970643
You need to log in before you can comment on or make changes to this bug.