SUN Classic / Exact VM

Java 的第一批虚拟机

1996 年 Java 1.0 发布时，Sun 提供了两款 JVM：Classic VM 和 Exact VM。它们是 Java 虚拟机的鼻祖，虽然早已退出历史舞台，但理解它们有助于理解现代 JVM 为什么这样设计。

SUN Classic VM：一切的开始

Classic VM 是 Java 1.0 ~ Java 1.2 时代唯一的虚拟机，也是 Sun 的「亲儿子」。

技术特点

纯解释执行

Classic VM 没有 JIT 编译器，它执行字节码的方式是：逐行解释执行。每一条字节码指令都被翻译成机器码，然后执行。

// 在 Classic VM 中，这段代码的执行过程：
public void calc() {
    int sum = 0;
    for (int i = 0; i < 100; i++) {  // 每次循环：解释 → 翻译 → 执行
        sum += i;                       // 没有任何缓存，每次都是新的翻译
    }
}

没有 JIT 意味着什么？慢。纯解释执行的 Java 程序，速度大约是 C/C++ 的 10~20 倍慢。这也是早期 Java 被批评「慢」的主要原因。

唯一可用的 GC

Classic VM 已经支持垃圾回收，但当时的 GC 非常原始——标记-清除（Mark-Sweep），没有分代，没有增量，没有任何优化。GC 一跑起来，整个程序就停顿（Stop-The-World）。

// Classic VM 的 GC 行为：
// 1. 程序全部停顿
// 2. 遍历所有对象，标记可达对象
// 3. 清除所有未被标记的对象
// 4. 程序恢复运行
// 停顿时间：可能长达数秒

淘汰原因

Classic VM 的局限性太明显：

• 没有 JIT：解释执行效率太低
• GC 原始：停顿时间不可控
• 无法优化：热点代码得不到特殊处理

2000 年 Java 1.3 发布后，HotSpot VM 取代了 Classic VM 的地位。

Exact VM：过渡期的尝试

Exact VM 是 Sun 在 Java 1.1 时期短暂使用的一款虚拟机（只存在于 Solaris 操作系统上），存在时间很短，设计理念却很超前。

名字的含义：「准确式」GC

Exact（准确式）的名字来源于它的核心特性：能够准确知道内存中每个位置的数据类型。

这听起来理所当然，但早期的 GC 做不到。Classic VM 在 GC 时需要「猜测」某个内存位置是什么类型的对象（通过检查对象的头信息）。

Exact VM 引入了一种机制，让 GC 能够准确识别每个对象的类型和边界，这让 GC 的效率更高，也为后来的分代 GC 打下了基础。

技术亮点

Classic VM         Exact VM
  ↓                 ↓
"猜测"对象类型      "准确"知道对象类型
GC 效率低           GC 效率更高
没有内联优化        支持内联优化

Exact VM 在内部引入了准确式类型信息（Exact Typing），使得：

• GC 的标记阶段更准确
• JIT 编译器可以进行更安全的内联优化
• 异常处理更精确

为 HotSpot 铺路

Exact VM 虽然很快被 HotSpot 取代，但它的一些核心思想被 HotSpot 继承了下来：

• 准确式内存管理
• 基于热点的分层编译（Exact VM 已经引入了部分概念）

从历史角度看，Exact VM 是 Classic VM 和 HotSpot VM 之间的「过渡实验」。

历史地位

1996  Classic VM ──→ Java 1.0
         │
         ├── 纯解释执行，没有 JIT
         ├── 原始的标记-清除 GC
         └── 速度慢，被批评为「沙发上的 Java」
                      │
1997  Exact VM  ──→ Java 1.1（Solaris only）
         │
         ├── 引入「准确式」GC 概念
         ├── 部分 JIT 能力
         └── 过渡产品，很快被 HotSpot 取代
                      │
1999  HotSpot VM ──→ Java 1.3（及以后所有版本）
         └── 成为 Java 的标准虚拟机

给我们的启示

理解 Classic 和 Exact VM 的局限性，才能理解 HotSpot 为什么这样设计：

1. 为什么 HotSpot 要有 JIT？ —— Classic VM 纯解释太慢，JIT 能把热点代码编译成本地机器码
2. 为什么 HotSpot 要有分代 GC？ —— Classic VM 的全堆扫描太慢，分代让 GC 只扫描需要回收的区域
3. 为什么 HotSpot 要「准确式」？ —— Exact VM 证明了准确知道对象类型能带来更好的优化机会

技术演进从来不是凭空出现的，每一个设计决策背后都有它的历史原因。

本节小结

虚拟机	时间	核心特点	地位
Classic VM	1996~2000	纯解释执行，原始 GC	Java 第一代 VM，已淘汰
Exact VM	1997~1999	准确式内存管理，部分优化	过渡产品，已淘汰

它们是历史的见证者，而 HotSpot 是站在它们肩膀上的集大成者。

下一节，我们来看看 HotSpot VM（核心），这是整个 Java 生态最重要的虚拟机。