The V8 Engine Series II: Bytecodes Vs Machine Codes

6 min readJun 20, 2024

Introduction

In the realm of JavaScript engines, performance is everything. V8, the engine behind Google Chrome and Node.js, is known for its speed and reliability. A common question is why V8 uses bytecodes, an intermediate representation, instead of compiling JavaScript directly into machine code for faster execution. Although bytecodes might seem like they slow things down, the reality is more nuanced. Let’s explore why V8 uses bytecodes and the benefits they bring.

The Early Days of V8

Why not just use the faster machine codes directly, V8? Would not the introduction of intermediate bytecodes slow down the whole process? In theory, yes. But that’s not the whole story.

Initially, V8 compiled JavaScript directly into machine code. The process involved several steps:

Parsing JavaScript: V8 parses the JavaScript source code into an Abstract Syntax Tree (AST) and scopes.
Initial Compilation: A compiler then converts the AST and scopes into machine code.
Hot Code Identification: V8 identifies frequently executed machine code instructions, tagging them as “hot.”
Optimization: A second compiler, specifically designed to handle hot code, compiles these sections into highly optimized machine code.
De-optimization: If the optimized code fails, V8 can revert to a less optimized version, ensuring robustness.

While effective, this process had significant drawbacks, particularly in memory usage and handling different CPU architectures.

Introduction of Bytecodes

To overcome these challenges, V8 introduced bytecodes. Bytecodes act as a middle layer between JavaScript and machine code, offering several key advantages.

Ignition and Bytecodes

Compiling bytecode to machine code is easier if the bytecode is designed with a similar computational model to the physical CPU. Ignition, V8’s interpreter, is a register machine with an accumulator register.

Let’s dive into a practical example to understand how V8’s bytecode works. This example is taken from Franziska Hinkelmann’s article).

Here’s a simple JavaScript function:

function incrementX(obj) {
  return 1 + obj.x;
}
incrementX({x: 42});
// V8's compiler is lazy, if you don't run a function, it won't interpret it.

When we run this function in Node.js and print the bytecode, it looks something like this:

$ node --print-bytecode incrementX.js
...
[generating bytecode for function: incrementX]
Parameter count 2
Frame size 8
  12 E> 0x2ddf8802cf6e @    StackCheck
  19 S> 0x2ddf8802cf6f @    LdaSmi [1]
        0x2ddf8802cf71 @    Star r0
  34 E> 0x2ddf8802cf73 @    LdaNamedProperty a0, [0], [4]
  28 E> 0x2ddf8802cf77 @    Add r0, [6]
  36 S> 0x2ddf8802cf7a @    Return
Constant pool (size = 1)
0x2ddf8802cf21: [FixedArray] in OldSpace
 - map = 0x2ddfb2d02309 <Map(HOLEY_ELEMENTS)>
 - length: 1
           0: 0x2ddf8db91611 <String[1]: x>
Handler Table (size = 16)

We can ignore most of the output and focus on the actual bytecodes. Here is what each bytecode means, line by line.

LdaSmi [1] loads the constant value 1 in the accumulator.
Next, Star r0stores the value that is currently in the accumulator, 1, in the register r0.
r0LdaNamedProperty a0, [0], [4] loads a named property of a0 into the accumulator. we look up a named property on a0, the first argument of incrementX(). The name is determined by the constant 0. LdaNamedPropertyuses 0 to look up the name in a separate table:

length: 1
           0: 0x2ddf8db91611 <String[1]: x>

Here, 0 maps to x. So this bytecode loads obj.x.

What is the operand with value 4 used for? It is an index of the so-called feedback vector of the function incrementX(). The feedback vector contains runtime information that is used for performance optimizations.

4. Add r0, [6] The last instruction adds r0 to the accumulator, resulting in43. 6 is another index of the feedback vector.

5. Return returns the value in the accumulator. That is the end of the function incrementX(). The caller of incrementX() starts off with 43 in the accumulator and can further work with this value.

At a first glance, V8’s bytecode might look rather cryptic, especially with all the extra information printed. But once you know that Ignition is a register machine with an accumulator register, you can figure out what most bytecodes do.

Benefits of Bytecodes

1. Memory Efficiency

Machine code is low-level instructions specific to CPU architecture. When JavaScript is compiled into machine code, the size of the resulting code can be enormous. For example, a 10KB JavaScript file could balloon into 20MB of machine code. This huge increase poses problems:

Memory Consumption: Large machine codes can exhaust memory, especially on devices with limited resources, such as mobile phones and embedded systems.
Caching Issues: Browsers often cache compiled code to improve performance on subsequent page loads. However, caching large machine codes can be impractical due to their size.

ytecodes offer a more memory-efficient alternative. In the same scenario, a 10KB JavaScript file might expand to only about 80KB when compiled into bytecodes. Although bytecodes are still larger than the original JavaScript source, they are significantly smaller than the equivalent machine code. This reduced size brings several benefits:

Lower Memory Footprint: Bytecodes occupy less memory, making them suitable for a broader range of devices.
Improved Caching: The smaller size of bytecodes makes it feasible for browsers to cache them, enhancing performance by skipping some intermediate steps during subsequent executions.

2. Compilation and Execution Speed

Machine codes are highly optimized for execution but require longer compilation times. Compiling JavaScript directly into machine code involves detailed analysis and optimization, which can be time-consuming. This longer compilation phase can lead to delays, particularly noticeable when loading web pages or starting applications.

Bytecodes, on the other hand, can be compiled much faster. The V8 engine uses a component called Ignition, a fast interpreter that quickly compiles JavaScript into bytecodes. This swift compilation process ensures that JavaScript code is ready to run almost immediately, reducing initial load times.

While machine codes execute faster than bytecodes due to their direct correspondence with CPU instructions, the overall performance difference is not as straightforward as it might seem. The execution speed of JavaScript involves a trade-off between compilation time and execution efficiency. Here’s how V8 handles this balance:

Initial Execution: V8 first compiles JavaScript into bytecodes using Ignition, allowing for rapid startup.
Hot Code Optimization: As the code runs, V8 identifies frequently executed sections (hot code). These sections are then compiled into highly optimized machine code by another component, TurboFan.
De-optimization: If assumptions made during optimization are invalidated (e.g., due to dynamic type changes), V8 can de-optimize the code, falling back to a less optimized but safer version.

This multi-tiered approach ensures that JavaScript execution is both fast and efficient, balancing the need for quick startup with the benefits of optimized execution.

3. Cross-Platform Compatibility

Machine codes are inherently tied to specific CPU architectures. Different processors, such as ARM, ARM64, x64, and S397, have distinct instruction sets. Writing and maintaining a JavaScript engine that directly compiles to machine code for each of these architectures would be complex and error-prone. The engine would need separate code paths for each CPU type, leading to increased development and maintenance efforts.

Bytecodes provide a solution by acting as an intermediate representation that is platform-agnostic. V8 compiles JavaScript into bytecodes, which are then interpreted or further compiled into machine code appropriate for the target CPU. This approach offers several advantages:

Simplified Development: By compiling JavaScript into a single intermediate form, the V8 team can focus on optimizing the bytecode interpreter and compiler. The same bytecodes can be executed on any platform with a compatible runtime.
Easier Portability: Introducing bytecodes simplifies porting V8 to new CPU architectures. Only the final compilation step needs to be adapted to the specific CPU, rather than the entire JavaScript-to-machine-code pipeline.
Consistency: Bytecodes ensure consistent behavior across different platforms. Since the initial compilation to bytecodes is platform-independent, developers can be confident that their code will run similarly on various devices.

In conclusion, while bytecodes may initially seem like an added complexity, they play a vital role in enhancing the performance, efficiency, and compatibility of JavaScript execution in the V8 engine. This strategic use of bytecodes allows V8 to deliver a powerful and optimized JavaScript experience across a wide range of devices and platforms.

Thank you for taking the time to read this article. I hope you found it insightful and engaging. Stay tuned for more, as there’s much more to come in this series, and don’t forget to read the previous parts in the series.