Detailed explanation of the execution process of JavaScript engine V8

1. V8 Source

The name V8 comes from the car's "V-type 8-cylinder engine" (V8 engine). The V8 engine was mainly developed in the United States and is widely known for its high horsepower. The V8 engine was named as Google's way of showing users that it is a powerful and high-speed JavaScript engine.

Before V8 was born, the early mainstream JavaScript engine was the JavaScriptCore engine. JavaScriptCore mainly serves the Webkit browser kernel, which is developed and open sourced by Apple. It is said that Google is not satisfied with the development speed and running speed of JavaScriptCore and Webkit, so Google started to develop a new JavaScript engine and browser kernel engine, so the two major engines V8 and Chromium were born, which have now become the most popular browser-related software.

2. V8 Service Target

V8 was developed based on Chrome, but it is not limited to the browser kernel. V8 has been applied in many scenarios so far, such as the popular nodejs, weex, quick applications, and early RN.

3. Early Architecture of V8

The V8 engine was born with a mission to revolutionize speed and memory recycling. The architecture of JavaScriptCore is to generate bytecode and then execute the bytecode. Google feels that the JavaScriptCore architecture is not feasible and that generating bytecode would waste time and would not be as fast as directly generating machine code. Therefore, V8 was very radical in its early architectural design, and adopted the method of directly compiling into machine code. Later practice proved that Google's architecture did improve speed, but it also caused memory consumption problems. You can look at the early flow chart of V8:

Early V8 had two compilers: Full-Codegen and Crankshaft. V8 first compiles all the codes once using Full-Codegen to generate the corresponding machine code. During the execution of JS, V8's built-in Profiler selects hot functions and records the feedback type of the parameters, and then passes them to Crankshaft for optimization. So Full-Codegen essentially generates unoptimized machine code, while Crankshaft generates optimized machine code.

IV. Defects of V8's Early Architecture

As versions were introduced and web pages became more complex, V8 gradually exposed its architectural flaws:

• Full-Codegen compilation directly generates machine code, resulting in large memory usage
• Full-Codegen compilation directly generates machine code, which leads to long compilation time and slow startup speed
• Crankshaft cannot optimize code blocks delimited by keywords such as try, catch, and finally
• Crankshaft adds new syntax support, which requires writing code to adapt to different CPU architectures

5. V8's current architecture

In order to solve the above shortcomings, V8 adopts the JavaScriptCore architecture to generate bytecode. Does it feel like Google has come full circle here? V8 uses the method of generating bytecode. The overall process is as follows:

Ignition is an interpreter for V8 and the original motivation behind it was to reduce memory consumption on mobile devices. Before Ignition, the code generated by V8's full-codegen baseline compiler typically occupied nearly a third of Chrome's overall JavaScript heap. This leaves less space for the actual data of your web application.

Ignition's bytecode can be used directly with TurboFan to generate optimized machine code without having to recompile from source code like Crankshaft. Ignition’s bytecode provides a cleaner and less error-prone baseline execution model in V8, simplifying the deoptimization mechanism, which is a key feature of V8’s adaptive optimizations. Finally, since generating bytecode is faster than generating Full-codegen’s baseline compiled code, activating Ignition will generally improve script startup times, and thus web page loading times.

TurboFan is an optimizing compiler for V8. The TurboFan project was originally launched in late 2013 to address the shortcomings of Crankshaft. Crankshaft can only optimize a subset of the JavaScript language. For example, it is not designed to optimize JavaScript code using structured exception handling, i.e. blocks of code delimited by JavaScript's try, catch, and finally keywords. It is difficult to add support for new language features in Crankshaft because these features almost always require writing architecture-specific code for the nine supported platforms.

Advantages of adopting the new architecture

The memory comparison of V8 under different architectures is shown in the figure:

Conclusion: It can be clearly seen that the memory usage of the Ignition+TurboFan architecture is reduced by more than half compared to the Full-codegen+Crankshaft architecture.

The comparison of web page speed improvements under different architectures is shown in the figure:

Conclusion: It can be clearly seen that the Ignition+TurboFan architecture improves the web page speed by 70% compared to the Full-codegen+Crankshaft architecture.

Next, we will briefly explain each process of the existing architecture:

6. Lexical Analysis and Syntax Analysis of V8

Students who have studied compiler theory know that a JS file is just a source code that cannot be executed by a machine. Lexical analysis is to split the source code string and generate a series of tokens. As shown in the figure below, different strings correspond to different token types.

After lexical analysis, the next stage is grammatical analysis. The input of grammatical analysis is the output of lexical analysis, and the output is the AST abstract syntax tree. When a syntax error occurs in the program, V8 throws an exception during the syntax analysis phase.

7. V8 AST Abstract Syntax Tree

The following figure is an abstract syntax tree data structure of the add function

After the V8 Parse stage, the next step is to generate bytecode based on the abstract syntax tree. As shown in the following figure, the add function generates the corresponding bytecode:

The function of the BytecodeGenerator class is to generate the corresponding bytecode according to the abstract syntax tree. Different nodes correspond to a bytecode generation function, and the function starts with Visit****. The function bytecode corresponding to the + sign is generated as shown below:

void BytecodeGenerator::VisitArithmeticExpression(BinaryOperation* expr) {
  FeedbackSlot slot = feedback_spec()->AddBinaryOpICSlot();
  Expression* subexpr;
  Smi* literal;
  
  if (expr->IsSmiLiteralOperation(&subexpr, &literal)) {
    VisitForAccumulatorValue(subexpr);
    builder()->SetExpressionPosition(expr);
    builder()->BinaryOperationSmiLiteral(expr->op(), literal,
                                         feedback_index(slot));
  } else {
    Register lhs = VisitForRegisterValue(expr->left());
    VisitForAccumulatorValue(expr->right());
    builder()->SetExpressionPosition(expr); // Save source code position for debugging builder()->BinaryOperation(expr->op(), lhs, feedback_index(slot)); // Generate Add bytecode }
}

From the above, we can see that there is a source code location record, and the following figure shows the correspondence between the source code and bytecode locations:

Generate bytecode, how to execute the bytecode? Next, let’s explain:

8. Bytecode

First, let's talk about V8 bytecode:

Each bytecode specifies its input and output as register operands

Ignition uses registers r0, r1, r2... and the accumulator register

registers: Function parameters and local variables are stored in user-visible registers

Accumulator: A non-user-visible register used to store intermediate results

The ADD bytecode is shown below:

Bytecode execution

The following series of figures show the changes in the corresponding registers and accumulators when each bytecode is executed. The add function passes in parameters 10 and 20, and the final result returned by the accumulator is 50.

Each bytecode corresponds to a processing function, and the address of the bytecode handler is saved in the dispatch_table_. When the bytecode is executed, the corresponding bytecode handler will be called for execution. The Interpreter class member dispatch_table_ stores the handler address for each bytecode.

For example, the processing function corresponding to the ADD bytecode is (when the ADD bytecode is executed, the InterpreterBinaryOpAssembler class is called):

IGNITION_HANDLER(Add, InterpreterBinaryOpAssembler) {
   BinaryOpWithFeedback(&BinaryOpAssembler::Generate_AddWithFeedback);
}
  
void BinaryOpWithFeedback(BinaryOpGenerator generator) {
    Node* reg_index = BytecodeOperandReg(0);
    Node* lhs = LoadRegister(reg_index);
    Node* rhs = GetAccumulator();
    Node* context = GetContext();
    Node* slot_index = BytecodeOperandIdx(1);
    Node* feedback_vector = LoadFeedbackVector();
    BinaryOpAssembler binop_asm(state());
    Node* result = (binop_asm.*generator)(context, lhs, rhs, slot_index,                            
feedback_vector, false);
    SetAccumulator(result); // Set the result of ADD calculation to the accumulator Dispatch(); // Process the next bytecode }

In fact, the JS code has been executed at this point. During the execution process, if a hot function is found, V8 will enable Turbofan for optimized compilation and directly generate machine code, so the following will explain the Turbofan optimization compiler:

9. Turbofan

Turbofan generates optimized machine code based on bytecode and hot function feedback types. Many of Turbofan's optimization processes are basically the same as the backend optimization of compilation principles, and it uses sea-of-node.

Add function optimization:

function add(x, y) {
  return x+y;
}
add(1, 2);
%OptimizeFunctionOnNextCall(add);
add(1, 2);

V8 has a function that can be called directly to specify which function to optimize. Execute %OptimizeFunctionOnNextCall to actively call Turbofan to optimize the add function. The add function is optimized based on the parameter feedback of the last call. Obviously, the feedback this time is an integer, so turbofan will optimize and directly generate machine code based on the parameter being an integer. The next function call will directly call the optimized machine code. (Note that --allow-natives-syntax is required to execute V8. OptimizeFunctionOnNextCall is a built-in function. Only with --allow-natives-syntax can JS call the built-in function, otherwise the execution will report an error).

The corresponding machine code generated by JS's add function is as follows:

This involves the concept of small integers. You can check this article https://zhuanlan.zhihu.com/p/82854566

If you change the input parameter of the add function to a character

function add(x, y) {
  return x+y;
}
add(1, 2);
%OptimizeFunctionOnNextCall(add);
add(1, 2);

The corresponding machine code generated by the optimized add function is as follows:

Comparing the two figures above, the add function passes in different parameters and generates different machine codes after optimization.

If an integer is passed in, it essentially calls the add assembly instruction directly

If a string is passed in, it essentially calls V8's built-in Add function

At this point, the overall execution process of V8 ends.

The above is a detailed explanation of the execution process of JavaScript engine V8. For more information about JavaScript engine V8, please pay attention to other related articles on 123WORDPRESS.COM!