dvander
unread,Sep 11, 2012, 4:11:46 PM9/11/12You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
Hi All,
IonMonkey has now landed on mozilla-central (yay!). Largely this shouldn't affect anyone doing SpiderMonkey development, but in case it does, here are the big takeaway changes:
(0) Benchmarks (usually) get faster. Compiling the shell does not. Sorry :(
(1) By running the shell, the flags "--ion -m -n" are now implied by default. You can disable them respectively with "--no-ion", "--no-jm", and "--no-ti". Disabling TI disables IonMonkey.
In the browser, there is one new JS pref: "javascript.options.ion.content". We don't expose any other flags since they'd only exist to horribly break stuff.
(2) IonMonkey, unlike JM, does not use the interpreter stack to store local variables and frames. It uses the C stack. This means that cx->fp(), js_GetTopStackFrame(), etc, must not be used unless with great care. Even if you have a js::StackFrame, it is not okay to peek at it because it could be stale.
When in doubt, use the wonderful ScriptFrameIter class. It has abstractions for walking the stack and inspecting frames so you don't ever have to touch a js::StackFrame.
(3) Lastly, IonMonkey introduces new ways to get in and out of the JIT. Briefly, they are:
(a) At function calls or loop edges, we may decide to run a script with IonMonkey. From C++, this goes through ion::Cannon.
(b) A guard failure, type-inference invalidation, or GC can cause a "bailout". A bailout is when an Ion frame on the stack must be converted back into an interpreter frame. When this happens, interpreter frames are created for each JS frame in the Ion frame (there can be multiple because of inlining), and we resume running the function in the interpreter instead.
-David