同一个Python程序，在标准CPython解释器下运行需要47秒，换成PyPy只需要2秒。代码完全相同，没有改动任何一行，性能却提升了23倍。这不是魔法，而是即时编译器（JIT）的功劳。

JIT编译器是编程语言实现中最精妙的技术之一。它位于解释器与编译器的交叉点，既要保证解释型语言的灵活性，又要逼近编译型语言的执行速度。要理解JIT如何做到这一点，需要深入到语言运行时的底层机制。

解释器的困境：每次都要"翻译"

传统的解释器采用"逐行翻译"的方式执行代码。考虑下面这段简单的JavaScript代码：

function sum(arr) {
  var total = 0;
  for (var i = 0; i < arr.length; i++) {
    total += arr[i];
  }
  return total;
}

当解释器执行这个函数时，它需要为循环的每一次迭代做以下工作：读取字节码指令、解析操作码、查找变量total的值、查找变量i的值、从数组arr中读取元素、执行加法运算、将结果写回变量total。这些"翻译"工作在每次迭代中都重复进行。

更关键的是，动态类型语言增加了额外的开销。total += arr[i]这行代码在JavaScript中可能意味着整数加法、浮点数加法、字符串拼接，甚至可能触发自定义的valueOf方法。解释器必须在每次执行时检查类型，然后选择正确的操作。这种检查的开销虽然单次很小，但在紧密循环中累积起来却相当可观。

编译型语言如C或Rust不存在这个问题。编译器在编译时就已经确定变量的类型和内存布局，生成的机器代码可以直接操作内存地址，无需任何运行时检查。这是编译型语言性能优势的核心来源。

JIT的核心理念：运行时编译

JIT编译器试图结合两种方式的优点。它的核心思想是：在程序运行时，将热点代码编译成机器码。

“热点代码"是JIT中的关键概念。1960年，John McCarthy在关于LISP的论文中首次提出了运行时编译的想法，但真正系统性地实现这一理念的是Smalltalk和Self语言的研究者。1984年，L. Peter Deutsch和Alan Schiffman在论文中描述了Smalltalk-80系统的动态编译技术，这被认为是现代JIT编译器的先驱。

Self语言的研究团队在1990年代进一步发展了JIT技术。Self是一门纯面向对象的原型语言，比Smalltalk更加动态——甚至连局部变量访问都需要方法调用。这种极端的动态性使得Self的执行效率成为严峻挑战。Urs Hölzle等人开发的第三代Self编译器引入了自适应优化（Adaptive Optimization）的概念：先用一个快速编译器生成初始代码，然后在运行时识别热点，再用优化编译器重新编译这些热点。

这个设计影响了后来的Java HotSpot虚拟机和各种JavaScript引擎。今天几乎所有的主流JIT都采用了类似的两阶段或多阶段策略。

热点检测：找到值得优化的代码

JIT首先要解决的问题是如何识别热点代码。最直观的方法是为每个方法或基本块维护一个执行计数器。当计数器超过某个阈值时，就触发编译。

不同JIT实现的阈值差异很大。PyPy在函数执行约1619次后开始追踪（tracing），执行约3000次后才开始获得性能提升。JVM HotSpot默认在方法执行10000次后触发编译。V8的基线编译器在函数执行约100次后就会介入。

计数器方法简单有效，但存在一个问题：它只看执行次数，不看代码的实际重要性。一个在启动时执行很多次但之后不再运行的初始化代码，和一个在核心循环中反复执行的代码，对计数器来说是一样的。

更精细的热点检测会考虑代码的"温度”。JIT会区分"warm"（较热）和"hot"（很热）的代码，采用不同的优化级别。这引出了分层编译的概念。

分层编译：渐进式的优化策略

现代JIT通常采用分层编译（Tiered Compilation）。以JVM HotSpot为例，它包含两个编译器：C1（客户端编译器）和C2（服务端编译器）。代码的执行路径如下：

  1. 解释执行：代码首次运行时由解释器执行，同时收集 profiling 信息。
  2. C1编译：当代码变"warm"时，C1编译器介入。它编译速度快，生成的代码比解释执行快，但优化程度有限。
  3. C2编译：当代码变"hot"时，C2编译器介入。它花更多时间做优化，生成最高质量的机器码。

JavaScriptCore（Safari的JavaScript引擎）更激进，拥有四个执行层级：

  1. LLInt：低级解释器，处理所有代码的初始执行。
  2. Baseline JIT：快速编译，生成未优化的机器码。
  3. DFG JIT：数据流图编译器，做中等程度的优化。
  4. FTL JIT：比光速还快的编译器（名字来源于"比编译时间还快的编译"的调侃），做最激进的优化。

分层编译解决了一个根本性的权衡：编译时间 vs 代码质量。优化编译需要时间，如果花在编译上的时间比节省的执行时间还多，那就是亏本生意。分层编译让JIT可以根据代码的重要性分配资源：只对真正值得的代码做深度优化。

内联缓存与隐藏类：动态语言的加速器

动态类型语言最大的性能障碍是属性访问。在Java中，访问对象的字段只需要一次内存加载指令，因为编译时就知道字段在对象中的偏移量。但在JavaScript或Python中，访问obj.x需要查找对象的结构，确定x属性的位置，这可能涉及哈希表查询或链表遍历。

V8引擎引入了**隐藏类（Hidden Class）**来解决这一问题。每个对象在内部都有一个隐藏类指针，描述对象的结构（有哪些属性，存储在哪些偏移量）。当给对象添加新属性时，隐藏类会发生转换：

初始状态：对象有隐藏类C0（空）
添加属性x：隐藏类变为C1，记录x在偏移量0
添加属性y：隐藏类变为C2，记录y在偏移量1

关键在于，用相同方式创建的对象会共享隐藏类。如果隐藏类相同，属性的偏移量就相同，这为优化打开了大门。

但仅仅有隐藏类还不够。每次访问属性时，仍然需要查找隐藏类确定偏移量。这时**内联缓存（Inline Cache）**出场了。内联缓存的观察是：同一个函数调用点，通常接收相同类型的对象。

当函数function getX(obj) { return obj.x; }第一次被调用时，V8会记录传入对象的隐藏类和对应的属性偏移量。第二次调用时，如果传入对象的隐藏类相同，V8就直接使用缓存的偏移量，跳过查找过程。如果隐藏类不同，才会回退到完整的查找逻辑。

这个技术大幅加速了动态语言的属性访问。但它也有代价：如果同一个调用点频繁接收不同类型的对象，内联缓存会不断失效，性能反而下降。这就是为什么JavaScript性能优化指南建议"保持对象结构一致"。

逃逸分析：消除不必要的对象分配

逃逸分析（Escape Analysis）是JIT的另一项重要优化。它分析对象是否"逃逸"出当前方法——如果对象只在方法内部使用，没有被返回或传递给其他方法，那就不需要在堆上分配它。

考虑这段Java代码：

public int calculate(int a, int b) {
    Point p = new Point(a, b);
    return p.x + p.y;
}

Point对象只在这个方法内使用，显然不会逃逸。HotSpot的C2编译器可以识别这种情况，将对象的字段"标量替换"为局部变量。实际执行的代码等效于：

public int calculate(int a, int b) {
    int p_x = a;
    int p_y = b;
    return p_x + p_y;
}

这完全消除了对象分配的开销，也避免了垃圾回收的压力。在理想情况下，逃逸分析可以让Java代码达到C语言的内存效率。

但逃逸分析也有局限性。它需要跨方法分析，复杂度高，而且很多情况下对象确实会逃逸。HotSpot的逃逸分析曾长期存在精度问题，在JDK 7u40之后有显著改进，但仍不完美。

去优化：当假设失效时

JIT的优化往往是基于假设的。内联缓存假设后续调用会使用相同类型的对象；逃逸分析假设对象不会逃逸；类型特化假设变量类型不会变化。这些假设在大多数时候成立，但动态语言的特性决定了它们可能随时被打破。

当假设失效时，JIT必须能够回退。这个过程叫去优化（Deoptimization）。去优化要解决一个复杂的问题：如何从优化后的机器码状态安全地恢复到解释执行状态？

考虑这段代码：

function process(data) {
  var sum = 0;
  for (var i = 0; i < data.length; i++) {
    sum += data[i];
  }
  return sum;
}

JIT可能基于data是整数数组的假设生成了优化的机器码。但在循环执行到一半时，如果data[i]突然变成字符串，假设失效了。这时需要暂停机器码执行，重建解释器所需的执行状态（栈帧、局部变量、程序计数器），然后继续解释执行。

**栈上替换（On-Stack Replacement, OSR）**是支持这种转换的关键技术。它允许在方法执行中途切换代码版本——从解释器切换到编译器，或从低优化级别切换到高优化级别，当然也包括反向的去优化。

OSR的实现相当复杂。编译器需要在代码中插入"安全点"（safepoints），在这些点上可以安全地暂停和转换。同时，编译器需要记录足够的信息来重建执行状态，这增加了内存开销。

方法JIT与追踪JIT：两种编译策略

JIT编译器有两种主要的编译策略：方法JIT（Method JIT）和追踪JIT（Tracing JIT）。

方法JIT以方法为编译单位。当某个方法成为热点时，JIT编译整个方法。这是JVM HotSpot和大多数Java JIT采用的方式。方法JIT的优点是实现相对简单，可以很好地处理非循环代码。缺点是如果方法很长但只有一小部分是热点，会浪费编译资源。

追踪JIT以执行路径（trace）为编译单位。它记录程序实际执行的路径，然后编译这条路径。PyPy和LuaJIT采用这种方式。追踪JIT在循环密集型代码上表现优异，因为一条trace通常就是一个完整的热循环。它避免了编译不执行的代码分支，生成的代码更加紧凑。

LuaJIT是最成功的追踪JIT实现之一。它由Mike Pall开发，在某些基准测试中甚至能够接近或超过C代码的性能。LuaJIT的秘诀在于：

  1. 一个高度优化的解释器，本身就很快
  2. 基于SSA的紧凑IR（中间表示）
  3. 精心调优的trace选择和编译策略
  4. 对x86/x64架构的深度优化

但追踪JIT也有弱点。如果程序的控制流复杂，频繁在不同路径间跳转，trace可能会"爆炸"——产生大量重叠的trace，消耗大量内存。这也是为什么追踪JIT在某些场景下不如方法JIT的原因。

Copy-and-Patch：Python 3.13的JIT新尝试

2024年1月，CPython核心开发者Brandt Bucher提交了一个PR，为Python 3.13添加了实验性的JIT编译器。这个JIT采用了一种叫copy-and-patch的技术。

Copy-and-patch是一种模板JIT。它的核心思想是：预先为每种字节码指令生成机器码模板，运行时只需"复制"模板并"修补"参数，就能快速生成可执行代码。

与传统的JIT不同，copy-and-patch不需要在运行时进行复杂的编译优化。所有的优化工作都在编译Python时由C编译器完成了。这大大降低了JIT本身的复杂度和运行时开销。

目前Python 3.13的JIT还处于实验阶段，性能提升只有2-9%。但这只是第一步。有了JIT基础设施，后续可以逐步添加更复杂的优化。CPython团队选择了一条渐进式的道路：先让JIT跑起来，再逐步完善。

JIT vs AOT：权衡的艺术

即时编译与提前编译（AOT）之间的选择，本质上是在启动时间、峰值性能和灵活性之间做权衡。

AOT的优势：

  • 启动快，没有编译延迟
  • 内存占用小，不需要存储编译器和编译后的代码
  • 可预测的性能，没有去优化带来的抖动

JIT的优势：

  • 可以利用运行时信息做优化
  • 可以做投机性优化（speculative optimization）
  • 代码可以随运行环境自适应

GraalVM的Native Image是AOT的典型代表。它可以在编译时将Java应用编译成原生可执行文件，启动时间从秒级降到毫秒级。但代价是失去了JIT的运行时优化能力，峰值性能可能不如传统JVM。

一个有趣的现象是：在某些场景下，JIT可以比AOT更快。原因是JIT可以利用运行时的具体信息做优化。例如，一个泛型方法在AOT中必须处理所有可能的类型，但JIT可以观察到实际只使用了整数类型，然后生成专门针对整数的优化代码。这就是所谓的"投机性优化"。

GraalVM甚至支持"混合模式"：用AOT保证快速启动，用JIT提升长期性能。这可能是未来的发展方向。

JIT的阴暗面：安全挑战

JIT编译器在安全方面面临独特的挑战。因为它需要在运行时生成可执行代码，这为攻击者提供了可乘之机。

**JIT喷射（JIT Spraying）**是一种针对JIT的攻击技术。攻击者构造特定的输入，使得JIT生成的机器码中包含恶意的payload。由于JIT生成的代码页面通常是可写可执行的（W^X原则的例外），攻击者可能利用这一点执行任意代码。

2010年，Dion Blazakis在Black Hat上发表了关于JIT喷射的开创性研究。他展示了如何利用JavaScript的字符串操作，诱导JIT生成包含shellcode的机器码。这项研究促使浏览器厂商加强了JIT的安全防护，比如在生成代码后将其标记为只读可执行。

现代JIT还面临侧信道攻击的风险。Spectre漏洞就是利用了CPU的投机执行特性，而JIT的投机性优化可能加剧这类风险。浏览器厂商不得不在性能和安全之间做艰难的权衡，在某些情况下甚至禁用了部分优化。

写在最后

JIT编译器的发展历程体现了软件工程的一个普遍模式：在约束条件下寻找最优解。解释器太慢，编译器太僵化，JIT在两者之间找到了一条中间道路。

从1960年McCarthy的想法，到Self语言的自适应优化，再到今天V8、HotSpot、PyPy等成熟实现，JIT技术走过了60多年的历程。每一次进步都源于对性能的追求和对灵活性的坚持。

JIT不是万能的。它有自己的代价：启动延迟、内存开销、实现复杂度、安全风险。但对于动态语言来说，JIT几乎是获得高性能的唯一可行路径。Python 3.13迈出了第一步，未来还有很长的路要走。

理解JIT的工作原理，有助于写出更适合JIT优化的代码。保持对象结构一致、让热点代码保持简单、避免在循环中改变类型——这些看似琐碎的细节，都可能影响JIT能否发挥最大功效。

参考资料

  1. Aycock, J. (2003). A Brief History of Just-In-Time. ACM Computing Surveys, 35(2), 97-113.
  2. Deutsch, L. P., & Schiffman, A. M. (1984). Efficient Implementation of the Smalltalk-80 System. POPL ‘84.
  3. Hölzle, U. (1994). Adaptive Optimization for Self: Reconciling High Performance with Exploratory Programming. PhD thesis, Stanford University.
  4. Mozilla Hacks. (2017). A Crash Course in Just-in-Time (JIT) Compilers.
  5. V8 Blog. TurboFan JIT. https://v8.dev/blog/turbofan-jit
  6. PyPy Speed Center. https://speed.pypy.org/
  7. Bucher, B. (2024). Python 3.13 JIT Implementation. CPython Pull Request.
  8. Shopify Engineering. (2022). When is JIT Faster Than A Compiler?