7

我试图理解将 java 实现为抽象机或虚拟机的真正优势，或者换句话说，将语言编译为抽象机语言的优势。就平台独立性而言，我正在考虑以下两种替代实现：

  • 只是有一个解释器，它可以将 java 直接翻译成它正在运行的机器的机器代码，并且对于不同类型的机器有多个这样的解释器实现。

  • 第一个选项在空间上效率不高，那么如何将源代码编译为一种中间语言，这种语言不是抽象机器的语言，而只是可以解释为机器代码的某种语言，然后具有此类解释器的多个实现。

如果不考虑性能，那么拥有抽象机器与这些选项相比如何。换句话说，如果 java 字节码不是虚拟机的语言，而只是某种中间语言会怎样。会失去哪些特性和好处（性能除外）？

4

4 回答 4

5

字节码只是一种中间语言。

或者反过来：中间语言的实现是虚拟机。

于 2012-05-09T07:13:51.803 回答
2

如果 Java 在执行时直接转换为机器代码，您将失去编译器提供的类型安全特性。编译器不报告错误的事实保证了某些类型的错误不会在运行时发生；如果您删除编译器阶段，您会在运行时看到这些错误。

另一方面，Java 字节码是一种中间语言，即使它比其他语言高一点。JVM 部分通过解释和部分通过编译为机器代码来执行它。

于 2012-05-09T07:02:01.623 回答
2

您所描述的本质上是 Java 和 JVM 目前所做的。Java 被编译成一种叫做bytecode的东西，它是一种中间语言（它看起来很像基于堆栈的机器的汇编）。然后 JVM 解释这个代码，在一个叫做Just In Time (JIT) 编译的过程中将它的一部分动态地翻译成机器代码。JVM 做其他有助于可移植性的事情（如管理并发和内存结构/管理）。

于 2012-05-09T07:06:08.757 回答
-1

所有变体实际上都在实践中使用，这都是关于选择适当的折衷方案。

对于 Java - 方便许多平台分发，启动时间较慢：

  • 编译为字节码的 Java 源代码
  • 字节码解释和/或
  • 字节码 JIT 编译为机器码

对于 JavaScript - 最方便的分发/需要做很多工作才能使其快速）：

  • JavaScript 源代码解析+解释或 JIT 编译为机器代码

对于 .NET - AOT 具有 VM 语言的所有优点，同时保持快速启动时间，但主要锁定在一种目标系统类型：

  • C#/F#/VB/...编译成IL（中间语言/另一种字节码）
  • .NET IL 代码解释和/或
  • .NET IL JIT 编译为机器码或
  • .NET IL AOT 编译（提前）（主要是 x86）和分布式编译

这只是最常用的，但是您可以将 javascript 编译为字节码，将 java 预编译为机器代码，您甚至可以像 GWT 一样将 Java 编译为 javascript，等等（只有很多工作才能使其可用）

于 2012-05-09T07:28:10.090 回答