jvm的抽象机器概念

时间:2012-05-09 06:32:38

标签: java jvm vm-implementation

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

  • 只是有一个解释器,它将java直接转换为运行它的机器的机器代码,并为不同类型的机器提供多个这种解释器的实现。

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

如果不考虑性能,如何将抽象机器与这些选项进行比较。换句话说,如果java字节代码不是虚拟机的语言而只是一些中间语言会怎么样。什么功能和好处会丢失(性能除外)?

4 个答案:

答案 0 :(得分:5)

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

反之亦然:中间语言的实现是虚拟机。

答案 1 :(得分:2)

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

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

答案 2 :(得分:2)

您所描述的实质上是Java和JVM目前所做的事情。 Java被编译成一种名为 bytecode 的东西,它是一种中间语言(对于基于堆栈的机器来说,它看起来很像组装)。然后,JVM解释此代码,在一个名为Just In Time (JIT) compilation的过程中将其部分代码转换为机器代码。 JVM做了其他事情(比如管理并发和内存结构/管理),这有助于实现可移植性。

答案 3 :(得分:-1)

所有变体实际上都在实践中使用,它都是关于选择适当的妥协。

for Java - 方便许多平台分发,启动时间较慢:

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

用于JavaScript - 最方便的分发/为了使其快速完成许多工作):

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

for .NET - AOT具有VM语言的所有优点,同时保持快速启动时间,但主要锁定到一个目标系统类型:

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

这正是大多数人正在使用的东西,但你可以编译javascript到字节码,预编译java到机器代码,你甚至可以像Java一样编译Java到javascript等等(只有很多事要做才能做到可用)