Tag: jit

On 23th of January the code of Firefox 53 already merged into the stabilization tree. While working on the next releases the code of FF53 has time to stabilize before release on April 18th.

In FF53 a lot has happened. Narrowing down on the JITs, the following was committed:

CacheIR

CacheIR improved drastically in this release. The goal of this project is twofold. One part is to unify the inline caches (IC) stubs in Baseline and IonMonkey. As a result we will only have to implement a new stub once anymore, leading to less code duplication. Secondly it uses an intermediate representation allowing us to reuse parts between stubs.

Starting in this release IonMonkey uses this infrastructure for generating ICs. Also new ICs were ported and we have now complete coverage of JSOP_GETPROP (e.g. reading out obj.prop where obj is an object) and JSOP_GETELEM (e.g. reading out array[42]) in CacheIR. Besides this milestone inline caches for getting DOM expando properties (e.g. properties added on DOM objects) were added, getting own properties of expandos on DOM proxies and lookups of plain data properties on the WindowProxies.

Our regular contributor evilpie helped a lot with this effort and implemented a logger that shows when we are missing specific stubs. This allowed us to find missing edge cases on popular websites. This enabled optimizations notably on Google Docs and Twitter. This work will continue in FF54.

WebAssembly

Since we implemented the draft specification of WebAssembly, we haven’t stopped improving it, be it for throughput or for compilation time and we’ve been polishing our implementation to fix bugs and incorporate last-minute spec changes

In order to improve the experience we have moved validation on the helper thread and we’re doing more of the compilation in parallel. Lastly we added some optimizations to achieve better parallelism while compiling. As a result the compilation of WebAssembly code should be smoother.

IonMonkey

IonMonkey also got its fair share of improvements in this release.

On Google docs we noticed a lot of compilation time was spend in a particular function “FlagAllOperandsAsHavingRemovedUses”. We were able to decrease the time spent in the loop in that function by removing some extra checks. As a result this is now a very tight loop and not visible in profiles anymore.

We adjusted a part of our engine, IonBuilder, which job is to create an SSA graph from a JS script, to return a “Result” type. This annotation will makes it easier to differentiate between different kinds of failures and correctly act on them. It indicated places where we didn’t handle out of memory failures correctly. In the future it will also allow to backtrack after an inlining failure and continue compiling without having to restart over.

Another improvement that happened to IonBuilder is that we now split the creation of the Control Flow Graph (CFG) and the rest of what IonBuilder does. IonBuilder has a lot of different roles and as a result could be cleaner. Also this code is one of the few parts that cannot run on the background thread. This split simplifies the IonBuilder code a bit and allows us to cache the CFG. A recompilation should be a little bit faster now.

Taahir Ahmed added extra code to allow us to constant fold powers. With this code IonMonkey can now use the result of a power with constant, instead of executing it every time at runtime.

Addition to the team

I’m also happy to announce that Ted Campbell has joined the JIT team. He started January 9th and is located in the Toronto office. He is helping the CacheIR project and will also look into making new ECMAScript 2016 features faster in IonMonkey.

Closing notes

This is not a full list of the changes that happened, but should cover the big ones. If you want the full list I would recommend you read the bug list. I want to thank everybody for their hard work. If you are interested in helping out, we have a list of mentored bugs at bugsahoy or you can contact me (h4writer) online at irc.mozilla.org #jsapi.

Last week we signed off our hard work on FF52 and we will start working on FF53. The expected release date of this version is the 6th of March. In the meantime we still have time to stabilize the code and fix issues that we encounter.

In the JavaScript JIT engine a lot of important work was done.

WebAssembly has made great advances. We have fully implemented the draft specification and are requesting final feedback as part of a cross-browser Browser Preview in the W3C WebAssembly Community Group. Assuming the Browser Preview concludes without major changes before 52 is released, we’ll enable WebAssembly by default in 52.

Step by step our CacheIR infrastructure is improving. In this release primitive value getprop was ported to the CacheIR infrastructure.

GC sometimes needs to discard the compilations happening in the helper threads. It seemed like we waited for the compilation to stop one after another. As a result it could take a while till all compilations were discarded. Now we signal all threads at the same time to stop compiling and afterwards wait for all of them to finish. This was a major win in our investment to make sure GC doesn’t interrupt the execution for too long.

The register allocator also received a nice improvement. Sometimes we were adding spills (stack to/from registers moves) while they were not needed. A fix was added to combat this.

Like in every release a long list of differential bugs and crashes have been fixed as well.

This release also include code from contributors:

• Emanuel Hoogeveen improved our crash annotations. He noticed that we didn’t save the crash reason in our crash reports when using “MOZ_CRASH”.
• Tooru Fujisawa has been doing incredible work throughout the codebase.
• Johannes Schulte has landed a patch that improves code for “testArg ? testArg : 0.0” and also eliminates needless control flow.
• Sander Mathijs van Veen made sure we could use unsigned integer modulo instead of a double modulo operation and also added code to fold additions with multiple constants.
• André Bargull added code to inline String.fromCodePoint in IonMonkey. As a result the performance should now be equal to using String.fromCharCode
• Robin Templeton noticed that we were spewing incorrect information in our debug logs and fixed that.
• Heiher has been updating MIPS to account for all changes we did to platform dependent code for WebAssembly.

I want to thank every one of them for their help! They did a tremendous job! If you are interested in helping out, we have a list of mentored bugs at bugsahoy or you can contact me (h4writer) online at irc.mozilla.org #jsapi.