The V8 scripting engine has a wide range of applications: Chrome, Node.js, Electron, Deno, etc. We front-end people might just focus on JavaScript or other tech stack syntax, simply understand EventLoop, call some WebAPI. Does not understand the inner workings of the V8 “black box”. Once you understand how JavaScript works, you can easily understand the syntax and lexing principles of Babel, the syntax checking mechanism of ESlint, the low-level implementation of Vue, React, and other frameworks. Let’s start with the history and core modules of the engine. Of course, this is also a very big topic, and each section could generate an article about hidden classes and embedded caches, memory management garbage collection mechanisms, Extension mechanisms, waiting for updates. Here are a few key points: 1. The origin of the V8 scripting engine. 2. Evolution of the V8 scripting engine. 3. V8 core module: parser, interpreter, optimized compiler.
The origin of the V8 scripting engine.
To understand the birth of V8, we need to understand that JavaScript is an interpreted language.
- Support dynamic type, weak type, at the time of the program to compile, efficiency is not low.
- Unlike compiled languages, source code cannot be translated directly into machine language; it is first translated into intermediate code, which is then interpreted and run by an interpreter.
- Programs don’t need to be compiled; they are translated into machine language at runtime, every time they are executed.
- In general,
Compiled languages run more efficiently than interpreted languages
; However, some interpreters for interpreted languages can even outperform compiled languages by dynamically optimizing their code at run time.
Understand the JS language is by the source code => intermediate code => machine language execution process, and JS to undertake more and more work, if there is no a dedicated script interpreter to its fast parsing execution and optimization, but only beforewebKit
In the defaultJavaScriptCore
The user experience will get worse and worse. The V8 engine was born without solving these problems.
When it comes toWebKit
“Before,What’s in a Browser anyway?It was mentioned in the articleRendering engineThere areTrident
.Gecko
.Webkit
Wait. Let’s just talkWebkit
The engine contains what, it and JS engine is how the relationship.
The earliestRendering engineIt included an interpreter for JS, which at the time was just for simple form submission, but wasn’t that powerful. This is aWebKit
The general structure ofIntroduction:
-
What do solid and dotted lines represent in the picture:
Solid line box
– Modules are all portedThere are some
.Dotted box
– Different manufacturers canTheir implementation
.
-
Operating system – a computer program that manages and controls computer hardware and software resources. It is the most basic system software that runs directly on the “bare machine”. Any other software must run under the support of the operating system. WebKit also works on operating systems.
-
Third party libraries – provide support for WebKit, such as graphics libraries, web libraries, video libraries, etc.
-
WebCore – is a shared part used by all browsers, including HTML parsers, CSS parsers, DOM, SVG, etc.
JavaScriptCore
– is itsThe default engine
, replaced with a V8 engine in the Google lineup.WebKit Ports
– It’s WebKitUnshared part
Because ofPlatform differences
,Third-party libraries
andDifferent needs
And so on, different ports led to WebKitDifferent versions
Behavior is inconsistent, which is a key part of the performance and functionality differences between browsers.
-
WebKit embedded programming interface – called by browsers, closely related to porting, different ports have different interface specifications.
-
Test cases, including layout test cases and performance test cases, are used to verify the correctness of rendered results. \
What is the relationship between A JS engine and a rendering engine?
JavaScript is an interpreted language in order toTo improve performance
.The introduction of
theThe Java virtual machine
andC + + compiler
In a number of technologies. The current JavaScript engine execution process looks like this:The source code
– –Abstract syntax tree
– –The bytecode
– –JIT
– –Native code
(V8 engines have no intermediate bytecode). Instead, the abstract syntax tree is JIT converted into native code, giving up some of the performance optimization that can be done in the bytecode stage, but keeping the execution speed.
Here we introduce why the V8 engine was born, the relationship between the JS interpreter and the rendering engine, and outline the implementation of the explanation. In the next chapter, we’ll take a look at V8’s evolution, what new features have been added at different times, and how to gracefully execute our JS code.
If this article can help or inspire you, it will be my pleasure