It is common knowledge that modern web applications run a lot more JavaScript code than a few years ago. Although compilers have quickly followed the trend and have made JavaScript efficient, for Mozilla a solution must be implemented to handle this workload even better.
To do this, Mozilla has developed and added a new bytecode interpreter JavaScript to its JavaScript rendering engine built into Firefox 70. With Firefox 70 available next October, Mozilla announces better JavaScript code management with using its new code interpreter added to its JavaScript engine.
To achieve this goal, Mozilla explains that In modern JavaScript engines, each function is initially executed in a code interpreter.
Functions that are called a lot are compiled into native machine code. This is called a JIT compilation or compilation on the fly. As to Firefox also includes a JavaScript code interpreter written in C ++ and various levels of JIT compilation.
First, we have a basic JIT compiler that compiles each bytecode statement directly into a small piece of machine code using inline caching for both performance and information gathering for the JIT compiler called IonMonkey or Ion.
In turn, the IonMonkey compiler uses advanced optimizations to generate quick code for critical options.
It should be noted that when a function that is already being compiled is called with a new type of argument, the code for the function can be "deoptimized" and discarded. In this case, execution continues in the base code until the next Ion build.
Although this process of interpreting the JavaScript code has worked quite well so far, the team at Firefox explains that it has encountered some problems with the first part made up of the C ++ interpreter and the base JIT compiler.
In fact, some modern web applications like Google Docs or Gmail run so much JavaScript that the compiler base and even the JIT compiler they could spend a long time trying to compile thousands of functions.
Also, the C ++ interpreter has been very slow and does not collect type information, delaying basic compilation. One solution would have been to pull it off the thread, but that would have been a performance risk.
To solve these problems, the folks at Mozilla comment that:
The base interpreter is between the C ++ interpreter and the base JIT compiler and contains elements of both levels.
Executes all bytecode statements with a fixed interpreter loop (like the C ++ interpreter), and uses inline caching techniques to improve performance and collect type information (like basic JIT does) .
Generating an interpreter is not a new idea. But the Firefox team points out here that they have found a new way to do this by reusing most of the basic JIT compiler code. The basic JIT compiler is a JIT model, which means that each intermediate code instruction is compiled into a substantially fixed sequence of machine instructions that are then suggested in an interpretation loop.
Also, since Firefox developers wanted the base interpreter to use the exact same online caches and the same information as JIT, a new data structure called JitScript was added.
JitScript contains all the type information and inline caching data structures used by the base interpreters and the JIT compiler.
With these new implementations, the basic compiler data for a function is now only in machine code. From there, all cached information and profiling data has been moved to JitScript.
On the other hand, since the base interpreter and the JIT compiler are identical, much of the generated code can also be shared.
To do this, a base class called BaselineCodeGen was created with 2 other derived classes. The base compiler uses the first class BalineCompiler to compile the bytecode of a script into machine code.
The second BaselineInterpreterGenerator class is used to generate the code for the base interpreter. And with the BaselineInterpreterGenerator class, the Firefox team managed to build the base interpreter.
Source: https://hacks.mozilla.org/