JavaScript是解释型语言--V8、JIT

编程语言

可以通过”语言“来控制计算机，让计算机为我们做事情。（类似于中文、英文）

编程语言是用来控制计算机的一系列指令（Instruction），它有固定的格式和词汇（不同编程语言的格式和词汇不一样），必须遵守，否则就会出错，达不到我们的目的。

编程语言的发展大概经历了以下几个阶段： 汇编语言 ==> 面向过程编程 ==> 面向对象编程

• 汇编语言是编程语言的拓荒年代，它非常底层，直接和计算机硬件打交道，开发效率低，学习成本高；
• C语言是面向过程的编程语言，已经脱离了计算机硬件，可以设计中等规模的程序了；
• Java、C++、Python、C#、PHP 等是面向对象的编程语言，它们在面向过程的基础上又增加了很多概念。

编程语言的从执行原理上分为两类：解释型语言和编译型语言

计算机不能直接理解机器语言以外的语言，因此需要将我们写的代码编译成机器语言，然后再交给计算机去执行。

编译型语言

程序在执行之前需要一个专门的编译过程，把程序编译为机器语言的文件，运行时不需要重新翻译，直接使用编译的结果就行了。程序执行效率高，依赖编译器，跨平台性差些。如C、C++、Delphi等。

解释型语言

程序不需要编译，程序在运行时才翻译成机器语言，每执行一次都要翻译一次。因此效率比较低。如 Python、Shell、JavaScript 等。

Java 语言

编译器（javac）把源代码转化为字节码，然后解释器（Java.exe）把字节码转换为计算机理解的机器码来执行。其中编译器和解释器都是 Java 虚拟机（JVM）的一部分，由于针对不同的硬件与OS，Java 解释器有所不同，因此可以实现“一次编译、到处执行”。所以 JVM 是Java 跨平台特性的关键所在 – 引入 JVM 后，Java 语言在不同平台上运行时不再需要重新编译。

对于前端开发同学使用的 JavaScript 语言，属于典型的解释型语言

JavaScript

JavaScript 作为编程语言的一种，直接输送给计算机（CPU）是不认识的（上面有提及），需要将其转换为指令集。不同类型的 CPU 的指令集是不一样的。JavaScirpt 引擎可以将 JavaScript 代码编译为不同 CPU（Intel, ARM 以及 MIPS 等）对应的机器码，同时引擎还可以执行代码、分配内存以及垃圾回收等。

Google V8 是开源高性能 JavaScript 和 WebAssembly 引擎，被用于 Chrome 和 Node.js 等。其中包括重要的四个模块：

1. Parser：将 JavaScript 源码转换为 Abstract Syntax Tree (AST)；
2. Ignition：解释器，将 AST 转换为 Bytecode，解释执行 Bytecode；同时收集 TurboFan 优化编译所需的信息，比如函数参数的类型；
3. TurboFan：编译器，利用Ignitio所收集的类型信息，将Bytecode转换为优化的汇编代码（计算机可识别）；
4. Orinoco：垃圾回收，负责将程序不再需要的内存空间回收。

整个转换过程：JavaScript ==> AST ==> Bytecode ==> Machine Code

关于 v8 引擎是如何工作的，可以看 这篇文章。

在 V8 出现之前，所有的 JavaScript 虚拟机所采用的都是解释执行的方式，这是 JavaScript 执行速度过慢的主要原因之一。而 V8 率先引入了即时编译（JIT）的双轮驱动的设计（混合使用编译器和解释器的技术），这是一种权衡策略，给 JavaScript 的执行速度带来了极大的提升。

绝大多数编译器以预先编译（AOT）或实时编译（JIT）形式工作。

• 使用命令行或者集成开发环境（IDE）调用预先编译（AOT）的编译器，如 gcc
• 实时编译器通常是用来提高性能的，令你没有感知的，如 V8

即时编译 JIT（Just-in-time）

解释器的工作方式：边解释，边执行。 对于循环等会存在解释多次的情况。从而导致运行速度变慢。

for (let i = 0; i < len; i++) {
     
  doSomething(i)
}

整体来说，为了解决解释器的低效问题，后来的浏览器把编译器也引入进来，形成混合模式。最终，结合了解释器和编译器的两者优点。

They added a new part to the JavaScript engine, called a monitor (aka a profiler). That monitor watches the code as it runs, and makes a note of how many times it is run and what types are used.

关于 JIT 的原理，大部分来自 这篇文章，英文好的同学可自行跳转查阅。

基本思想： 在 JavaScript 引擎中增加一个监视器（也叫分析器）。监视器（monitor）监控着代码的运行情况，记录代码一共运行了多少次、如何运行的等信息。后续遇到相同代码时，跳过解释，直接执行。

执行步骤

第一步：Interpreter

使用解释器执行，当某一行代码被执行了几次，这行代码会被打上 Warm 的标签；当某一行代码被执行了很多次，这行代码会被打上 Hot 的标签

第二步：Baseline compiler

被打上 Warm 标签的代码会被传给 Baseline Compiler 编译且储存，同时按照行数 (Line number) 和变量类型 (Variable type) 被索引。当发现执行的代码命中索引，会直接取出编译后的代码给浏览器执行，从而不需要重复编译已经编译过的代码。

第三步：Optimizing compiler

被打上 Hot 标签的代码会被传给 Optimizing compiler，这里会对这部分带码做更优化的编译（类型假设）。在执行前会做类型检查，看是假设是否成立，如果不成立执行就会被打回 interpreter 或者 baseline compiler 的版本，这个操作叫做 “去优化”。

JIT 会增加多余的开销：

• 优化和去优化开销
• 监视器记录信息对内存的开销
• 发生去优化情况时恢复信息的记录对内存的开销
• 对基线版本和优化后版本记录的内存开销

所以，整体来看是一个空间换时间的优化方案。当然，通过上述三个步骤，可得知，虽然 JavaScript 是弱类型语言，随意修改变量的类型会导致 JIT 编译效率下降（命中索引概率低）。

说在后面

对于整个解释型语言及现有的相关优化方式（JIT）了解之后，对于后续文章要提到的 esbuild 会有更好的理解。esbuild 也被称为下一代构建工具（使用 Go 语言编写，基于 ESM）。coming soon~~

esbuild：An extremely fast JavaScript bundler
Our current build tools for the web are 10-100x slower than they could be. The main goal of the esbuild bundler project is to bring about a new era of build tool performance, and create an easy-to-use modern bundler along the way.