Google is improving the performance of its V8 JavaScript engine with a new compiler: Sparkplug

Why write a new compiler to improve the JavaScript v8 engine? Google explains: There is more to writing a high-performance JavaScript engine than a highly optimized compiler like TurboFan. Especially for short sessions, such as loading websites or command line tools, there is a lot of work before the optimizer compiler has a chance to start optimizing, let alone start optimizing. Take the time to generate the optimal code.

This is why, since 2016, we have moved from monitoring synthetic standards (such as octane) to measuring real world performance, and why since then we have been working hard on JavaScript performance outside of compiler optimization. It took a lot of work on the parser, on the flow, on our object model, on competing garbage collection, and on caching the compiled code…let’s just say we’ve never been bored.

However, as we strive to improve the performance of the initial JavaScript runtime, we are starting to encounter limitations when optimizing our compiler. The V8 compiler is highly optimized and very fast, but interpreters have an inherent operating expense that we can’t get rid of.

With the current double compiler model, it is not possible to switch to optimized code faster. Optimization can be accelerated, but at some point you can only achieve this acceleration by removing the optimization lanes, which reduces peak performance.

This is where Sparkplug comes in, a new unoptimized JavaScript interpreter that Google is launching with V8 v9.1. Sparkplug is located between the ignition translator and the TurboFan optimization translator, forming a new pipeline.

Sparkplug is designed to translate quickly. It’s so fast that we can pretty much compile it when we want, allowing us to switch to Sparkplug code more robustly than we can to TurboFan code. Google says.

One reason for this speed is that the functions that Sparkplug compiles have already been compiled into bytecode, and the bytecode compiler has already done the heavy lifting. On the other hand, Sparkplug does not generate any intermediate representation (IR) as most compilers do. Instead, Sparkplug compiles directly to machine code in a single linear path through the bytecode, releasing a code that matches that bytecode implementation.

Since Sparkplug does not generate any intermediate representation, opportunities for optimization are limited, but this is not a problem as there is an optimized compiler in the pipeline.

Google introduces how Sparkplug works in this very interesting Technical note.