Categories

Meta

Tag: firefox 31

Spidermonkey, the JavaScript engine used in Mozilla Firefox, has undergone big changes in 2014. Just like I did last year I’ll go over the major changes that landed throughout the year. Though this time I’ll split the post into a series of three or four posts. This will allow me to explain the changes a bit more in depth and also keep the posts lighter.

Looking back at 2014 most changes that happened were to improve to the Garbage collection (GC) algorithm, improve our second (Baseline) and third tier compiler (IonMonkey) and implement the EcmaScript 6 (ES6) specification. After months of preparation 2014 was the year for our GC team. We finally came to a state where we improved the Garbage Collection algorithm dramatically. We also still kept looking to the Octane 2.0 benchmark while also other benchmarks started to get on our examination table more often (BrowserMark, jsbench, dromaeo …). Throughout the year we achieved again a 40% improvement to our Octane score and Browsermark 2.1 improved with 5%, showing the huge effort of everybody involved. Nexto performance improvements we also increased our efforts implementing the ES6 standard. While the standard isn’t released yet, it will get released soon and we want to support most things before that happens.

In this first part I will look at the first three releases that were developed in 2014: Firefox 29 to Firefox 31.

Firefox 29 a.k.a Australis

ARM simulator

Our JavaScript engine is tested quite elaborately on desktop machines (i686 and x86_64 chipset), but less extensively on phones (ARM chipset). Most developers don’t have spare systems running these chips and if they have it is quite hard to set up a testing environment. To improve the situation the ARM simulator of Chrome has been ported to Mozilla. This makes it possible to test, run or debug the biggest and most error prone part of the JavaScript engine (JIT code) on a regular desktop by simulating the ARM instructions. As a result phones should now experience an even more stable JavaScript engine.

Our highest and fastest tier to run JavaScript code, IonMonkey, was not able to recompile (Ion) code for a JS function while the old Ion code was still present. One had to first throw the old Ion code away, before starting a new IonMonkey compilation for that particular JS function. This was mostly not an issue since recompilation mostly happens when the old Ion code is not correct anymore (E.g. when we observed a new type). For a few cases this was not optimal. Therefore since this release we can recompile a JS function while keeping the old Ion code, until the compilation is finished. The benefits are twofold here. Recompiling a function with an entry at a loop nexto the function entry (OSR) is now less expensive. Secondly this might brings us closer to “Optimization levels” where we want to recompile a JS function with more optimizations, taking longer to compile, and in the meantime run the current old ion code.

In Firefox 29 ES6 Promises were also enabled by default. Though this is not really the work of the Spidermonkey team, but from the DOM team. Firefox is already using this improvement to the Javascript language, proposed for Harmony (ECMAScript 6) in the frontend extensively and now it was deemed that the specification about Promises wouldn’t change much anymore, making it safe to release on the web.

Most higher level languages, just like JavaScript, provide automatic memory management (Garbage collection). This removes the need for developers to free resources themself when they are not needed anymore. (I.e. when they are dead). Our current Garbage collection (GC) algorithm was approximate as it didn’t know exactly which objects were alive, so it had to be conservative. Exact stack rooting was all about changing that to make sure we now exactly which objects are live. This brings some overhead since we now must keep track of every object using a container (rooting), but it also is the most important thing needed before we can start experimenting with more advanced GC schemas like Generational GC and Compacting GC.

Firefox 30

EcmaScript 6: Generators

Basic support of ES6 generators has landed. This new feature adds the support of generator functions and the yield statement and got many people excited. Normally a function runs to completion and returns the result. This is different for generators. Such a function will stop at a yield instruction and upon next execution go further at that yield till the next yield or termination of that function. In this release the support for the Interpreter, our lowest tier, has landed.

JavaScript is a weakly typed or even untyped language. So every instructions has to work with every type. In order to specialize an instruction and make it faster the instructions get annotated with observed types (Type Inference). This works mostly fine, except at branches. It happens a lot at branches that a variable gets tested for being not null and undefined or having a specific type. This information gets lost and we keep using the full type information of that variable in the succeeding code. With this release an infrastructure has been added to reason about these branches in our highest optimization tier, IonMonkey and decrease the types accordingly.

IonMonkey was introduced in Firefox 18, more than a year ago, and it has been enabled by default for quite some time for normal scripts. But it wasn’t enabled for Firefox its own UI and addons (chrome content). Firefox only used the interpreter and baseline in that case. Since this release IonMonkey and TI sort of graduated and TI and IonMonkey for chrome scripts is now enabled by default. A huge win for addons, since they now can get the full JavaScript performance potential of IonMonkey.

Firefox 31

EcmaScript 6: more math methods

ES6 proposes a lot of new Math methods like Math.sign, Math.log2, Math.imul, Math.trunc, Math.cosh, Math.hypot … Most things were already possible to do in JS with some extra code, but now there are functions standardized, making it easier to perform such operations.

Faster ES6 arrow functions

This release also brought performance improvements to the arrow function introduced by ES6. Using arrow functions should now have a similar performance as normal functions, which means an improvement of up to 64 times. This is important since having bad performance for new ES6 features will also decrease the uptake of these new features and apparently our frontend Firefox developers already use this new feature a lot.

Just like a regular compiler IonMonkey needs to fit the used variables into a limited set of registers. This is done using a register allocator. IonMonkey has the ability to run with different register allocators. It uses by default LSRA, but also acquired a backtracking register allocator. This new allocator, based on the new register allocator used in LLVM 3.0, should be faster and improve the allocated registers. For octane-zlib this was an improvement of 21%. In this release this new allocator is enabled by default for asm.js code. Pending some bugs and performance issues on regular code, it will also get enabled by default in normal IonMonkey code in 2015.