三种编译技术比较_比较编译技术

Java应用程序性能有时在开发社区中引起了激烈的争论。 因为设计该语言是为了支持应用程序可移植性的关键目标而设计的，所以早期的Java运行时所提供的性能水平大大低于诸如C和C ++之类的编译语言所能达到的水平。 尽管此类语言可以在更高级别上执行，但是生成的代码只能在有限数量的系统上执行。 在过去的十年中，Java运行时供应商已经开发了复杂的动态编译器，通常称为即时（JIT）编译器。 JIT编译器在程序运行时有选择地将执行频率最高的方法编译为本机代码。 像使用C或C ++编写的程序一样，将本机代码编译延迟到运行时而不是在程序运行之前进行编译可以满足可移植性要求。 一些JIT编译器甚至不使用解释器就编译所有代码，但是这些编译器仍通过在程序执行时进行操作来保留Java应用程序的可移植性。

得益于动态编译技术的许多进步，现代的JIT编译器可以产生与各种应用程序的C或C ++静态编译性能相匹配的应用程序性能。 尽管如此，许多软件开发人员仍根据经验或轶事证据认为动态编译会严重干扰程序操作，因为编译器必须与应用程序共享CPU。 一些开发人员坚决认为要解决此性能问题，便强烈要求Java代码进行静态编译。 的确，对于某些应用程序和执行环境，静态编译可以极大地提高Java性能，或者是唯一的实用选择。 但是，静态编译Java应用程序时，要获得良好的性能会涉及许多复杂性。 普通的Java开发人员可能没有完全意识到动态JIT编译器的优势。

本文着眼于静态和动态地编译Java语言所涉及的一些问题，重点是对实时（RT）系统的影响。 它简要描述了Java语言解释器的操作方式，然后描述了由现代JIT编译器执行的本机代码编译的优缺点。 它介绍了IBM®在WebSphere®Real Time中发布的AOT编译技术，并介绍了它的一些优缺点。 然后，它比较和对比了两种编译策略，并指出了几个应用程序区域以及AOT编译可能是更好方法的执行环境。 要点是，这两种编译技术不是互斥的：两者的优缺点都影响每种技术最有效的应用程序类型。

执行一个Java程序

最初，通过Java SDK的javac程序将Java程序编译为与平台javac的本地格式，即类文件。 可以将这种格式视为Java平台，因为它定义了执行用Java语言编写的程序所需的所有信息。 Java程序的执行引擎（也称为Java运行时环境（JRE））包括一个虚拟机，该虚拟机为特定的本机平台实现Java平台。 例如，在AIX®操作系统上运行的基于Linux®的Intel®x86平台，Sun Solaris平台和IBM System p™平台均具有JRE。 这些JRE实现实现了正确执行为Java平台编写的程序所需的所有本机支持。

实际上，操作数栈的大小有实际限制，但是对于程序员而言，编写超出该限制的方法将是极为罕见的。 JVM提供了一个安全检查，通知确实设法创建这种方法的任何程序员。

Java平台程序表示的一个重要部分是一系列字节码 ，它们描述Java类中每个方法执行的操作。 字节码描述使用理论上无限大的操作数堆栈的计算。 这种基于堆栈的程序表示法提供了平台中立性，因为它不依赖于任何特定本机平台的CPU中可用的寄存器数。 可以独立于任何本机处理器的指令集定义在操作数堆栈上可以执行的操作。 这些字节码的执行由Java虚拟机（JVM）规范定义（请参阅参考资料 ）。 执行Java程序时，用于任何特定本机平台的任何JRE必须遵守JVM规范规定的规则。

由于很少有基于堆栈的本机平台（Intel X87浮点协处理器是一个明显的例外），因此大多数本机平台无法直接执行Java字节码。 为了解决这个问题，早期的JRE通过解释字节码来执行Java程序。 也就是说，JVM反复循环运行：

1. 获取下一个要执行的字节码。
2. 对其进行解码。
3. 从操作数堆栈中获取所需的操作数。
4. 根据JVM规范执行操作。
5. 将任何结果写回堆栈。

这种方法的优点是简单：JRE开发人员只需编写代码即可处理每种类型的字节码。 并且由于少于255个字节码可用于描述操作，因此实现成本较低。 当然，缺点是性能：尽管Java平台有许多其他优点，但许多人还是在早期就使用它来谴责Java平台。

解决诸如C或C ++之类的性能差距意味着要以不牺牲可移植性的方式为Java平台开发本机代码编译。

编译Java代码

尽管有轶事证据表明Java编程的“一次写入，遍地运行”的口号可能并非在所有情况下都严格符合要求，但它确实适用于各种应用程序。 另一方面，本机编译本质上是特定于平台的。 那么Java平台如何在不牺牲平台中立性的情况下实现本机编译性能？ 答案是并且已经十年来以JIT编译器的形式进行动态编译（参见图1）：

图1. JIT编译器

使用JIT编译器，Java程序在执行到本机处理器的指