jvm - 将虚拟机设计与其主要编程语言相匹配

Question

作为一个副项目的背景，我一直在阅读不同的虚拟机设计，当然 JVM 最受关注。我还研究了 BEAM(Erlang)、GHC 的 RTS(有点但不完全是 VM)和一些 JavaScript 实现。 Python 也有一个字节码解释器，我知道它存在，但没有阅读太多。

我还没有找到对 的一个很好的解释为什么要为特定语言做出特定的虚拟机设计选择 .我对适合并发和/或非常动态(Ruby、JavaScript、Lisp)语言的设计选择特别感兴趣。

编辑:为了回应要求具体的评论，这里是一个例子。 JVM 使用堆栈机而不是注册机，这在 Java 刚推出时是非常有争议的。事实证明，设计 JVM 的工程师这样做是为了平台可移植性，将堆栈机转换回寄存器机比克服虚拟寄存器过多或过少的阻抗不匹配更容易、更有效。

这是另一个例子:对于 Haskell，要查看的论文是 Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine .这与我所知道的任何其他类型的 VM 都非常不同。事实上，GHC(Haskell 的首要实现)不会实时运行，而是用作编译的中间步骤。 Peyton-Jones 列出了不少于 8 个其他无法运行的虚拟机。我想了解为什么某些 VM 会在其他 VM 失败的情况下成功。

Answer 1

我将从不同的角度回答您的问题:什么是 VM？虚拟机只是比源语言低级语言的“解释器”的规范。在这里，我使用了“解释器”这个词的黑匣子含义。我不在乎 VM 是如何实现的(作为字节码互译器、JIT 编译器等等)。用这种方式表述时，从设计的角度来看，VM 并不是有趣的东西，它是低级语言。

理想的 VM 语言将做两件事。一，它可以很容易地将源语言编译成它。第二，它也可以很容易地在目标平台上进行解释(同样，解释器可以非常天真地实现，也可以是一些非常复杂的 JIT，如 Hotspot 或 V8)。

显然，这两个理想属性之间存在张力，但它们或多或少会在所有可能的 VM 的设计空间的一条线上形成两个端点。 (或者，也许是一些比线更复杂的形状，因为这不是平坦的欧几里得空间，但您明白了)。如果你在这条线之外构建你的 VM 语言，那么它就不会很有用。这就是限制 VM 设计的原因:将其置于理想路线的某个位置。

这也是为什么高级 VM 往往是特定于语言的，而低级 VM 与语言无关，但不提供很多服务。高级 VM 本质上接近源语言，这使其远离其他不同的源语言。低级 VM 本质上靠近目标平台，因此接近许多语言的理想行的平台端，但该低级 VM 也离理想行的“易于编译到”端相去甚远。大多数源语言。

现在，更广泛地说，从概念上讲，任何编译器都可以看作是从源语言到中间形式的一系列转换，中间形式本身可以看作是 VM 的语言。可能永远不会构建用于中间语言的 VM，但它们可以。编译器最终会发出最终形式。最终形式本身将成为 VM 的一种语言。我们可能称该虚拟机为“JVM”、“V8”……或者我们可能称该虚拟机为“x86”、“ARM”等。

希望有帮助。