java - 使用 GraalVM 提升 JUnit 性能

Question

阅读了一些有关新 GraalVM 的高级文章，并认为使用它来增强 JUnit 测试性能是个好主意，特别是对于在 fork 模式下运行的大型测试套件。

根据SO question "Does GraalVM JVM support java 11?"我在 Eclipse 中的单元测试运行配置的 VM 参数中添加了以下内容(jee-2019-12、JUnit4):

-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler

效果:单元测试花费的时间比不使用这些开关的时间稍长(使用这些开关时为 2800 毫秒，不使用时为 2200 毫秒，可重现)。

我是不是错过了什么？或者我是否误解了 GraalVM 中增强启动时间的 promise ？

Answer 1

是的，不幸的是，感觉这里存在一些误解。我将在这里尝试详细阐述一些有关性能和 GraalVM 的问题。

GraalVM是一个多语言运行时，它可以运行 JVM 应用程序，通常它是通过运行 Java HotSpot VM(例如与 OpenJDK JDK 相同)来实现的，并将顶层优化即时 (JIT) 编译器替换为自己的 GraalVM 编译器。稍微简化一下，在运行期间，JVM 加载类文件，验证它们，开始解释它们，然后使用一系列编译器编译它们，这些编译器往往从编译速度最快到优化程度最高——因此应用程序运行的时间越长更多的你使用相同的方法——它们逐渐被编译成越来越好的机器代码。

GraalVM 编译器非常擅长优化代码，因此当您的应用程序运行足够的时间并且开始工作时，结果通常比其他编译器显示的要好。这会带来更好的峰值性能，这对于中/长期运行的工作负载来说非常有用。

您的单元测试运行需要 2 秒，对于大量执行代码、收集配置文件和使用优化编译器来说，这实际上并没有那么多时间。也可能是特定的代码模式和工作负载确实非常适合 C2(默认 HotSpot 的顶级 JIT)，因此很难做得更好。请记住，C2 是一个优秀的 JIT，它已经发展了至少二十年，而且它的结果也非常非常好。

现在 GraalVM 还为您提供了另一个选项 -- GraalVM native images ，它允许您提前将代码(AOT)编译为 native 二进制文件，该二进制文件不依赖于 JVM，并且不会加载类、验证它们、初始化它们，因此启动此类二进制文件直到它变得有用“业务”的工作要好得多。对于较短的运行工作负载或资源受限的环境来说，这是一个非常有趣的选项(二进制文件不需要进行 JIT 编译，因此不需要资源，从而使运行时资源消耗更小)。然而，要使用这种方法，您需要使用 GraalVM 的 native 镜像实用程序来编译应用程序，并且它可能需要比 2 秒内运行的工作负载更长的时间。

现在，在您描述的设置中，您没有使用 GraalVM 发行版，而是在 OpenJDK(我假设)发行版中启用 GraalVM 编译器。您指定的选项将 GraalVM 编译器打开为顶层 JIT 编译器。与从 GraalVM 发行版运行 java 相比，有两个主要区别:

• 编译器不是最新的，在某个时间点，GraalVM 编译器源代码被拉入 OpenJDK 项目，这就是它在您的发行版中的结束方式。
• GraalVM 编译器是用 Java 编写的，在您的设置中，它作为普通 Java 代码执行，因此它首先可能需要 JIT 编译自身，这会导致运行的预热阶段更长，其代码在一定程度上污染了 JIT 配置文件，等等

在 GraalVM 发行版中，我将 encourage you to try对于这个实验——GraalVM编译器是最新的，并且默认使用GraalVM native 镜像技术预编译为共享库，因此在运行时不需要进行JIT编译，因此它的预热更类似于C2的特点。

不过，2 秒可能不足以让优化编译器显示主要差异。也可能是测试一次运行了大量代码，而 JIT 编译的热代码主体不够重要。