HotSpot与OpenJ9：性能比较

选择哪种Java虚拟机，HotSpot 还是OpenJ9？两者都是可调的开源JVM实现。HotSpot是一个成熟的JVM实现，最初由Sun Microsystems开发。由IBM开发的OpenJ9在业界的应用并不广泛，但近年来得到了普及。

基于DayTrader7基准测试应用程序研究，OpenJ9声称在启动时间、延迟、吞吐量和内存占用方面表现出色，其中三种经过微调的OpenJ9配置与默认热点进行了比较。

BellSoft的工程师已决定检查是否可以配置HotSpot，以使其显示可比或更好的性能结果。您可以在下面找到他们的测试摘要。

https://github.com/eclipse-openj9/openj9-website/blob/master/benchmark/openjdk11-daytrader7.md

实验设置

我们使用原始研究中的DayTrader7应用程序（https://github.com/WASdev/sample.daytrader7）作为基准。它不是一个微服务应用程序，而是在web服务器上启动的一个小整体，因此我们认为这种配置最为显著。我们还将Linux上的服务器类机器和Windows上的桌面类机器用作平台，并将OpenJDK 11用作JDK二进制文件：采用带有三个OpenJ9标志配置的OpenJDK构建，以及带有默认和调优热点的Liberica JDK。

重点是启动时间、占用空间、延迟和吞吐量。ApacheJMeter 5.4.1用于测量后三个指标。

我们的目标不是通过热点微调技巧生成合成性能数据，而是评估这个JVM实现的标准设置。

结果

启动

有几个参数有助于减少热点应用程序的启动。第一种是应用程序类数据共享或AppCDS。它允许将应用程序类放置在共享存档中，从而加快启动速度。此功能出现在热点1.5中，并在后续版本中得到了改进。例如，现在可以自动生成存档。激活AppCD需要以下标志：

-XX:SharedArchiveFile=app-cds.jsa

请注意，必须显式创建AppCDS存档。上面的参数使您能够指定类存储的存档文件的名称。如果没有它，类将存储在JDK安装目录中，这是不可取的。创建存档后，您可以使用它启动应用程序，JVM将其映射到其内存中，并提供了它所需的大多数类。AppCDS文档可以在Oracle的网站上找到。

此外，-XX:TieredStopAtLevel=1参数使开发人员能够使用客户端（C1）编译器运行应用程序，而无需进行分析，从而提供更快的代码编译。此配置适用于启动加速是最高优先级的情况。

下面是与OpenJ9和HotSpot的启动时间比较。启动时间计算为启动时间与“应用程序daytrader7以X秒为单位启动”输出之间的差值。

测试配置：

• OpenJ9（1）（堆256MB）：“-Xmx256m”
• OpenJ9（2）（堆256 MB，类缓存）：“-Xmx256m-Xshareclasses:name=mvn”
• OpenJ9（3）（堆256 MB，类缓存，快速编译）：“-Xmx256m-Xshareclasses:name=mvn-Xtune:virtualized-Xscmx200m”
• HotSpot（堆256 MB）：“-Xmx256m”
• HotSpot（堆256 MB，AppCDS，C1）：“-Xmx256m-XX:SharedArchiveFile=app-cds.jsa-XX:TieredStopAtLevel=1”

具有上述参数的Liberica JDK显示了最好的结果（4.972毫秒），而除了堆大小限制之外没有其他参数的OpenJ9给出了最差的结果（6.986毫秒）。

Footprint

在我们的实验中，我们使用了daytrader7开发人员提供的DayTrader 7.jmx测试计划。根据机器类调整测试计划参数：服务器类机器使用四个线程，桌面类机器使用六个线程。

测试计划是一个脚本，包含许多模仿在线股票交易系统中用户工作的HTTP请求。用户可以登录/注销、查找投资组合或股票报价，以及买卖股票。

在测量统计数据之前，执行了一次虚拟机预热。之后，平均进行5-7次迭代，每次迭代120-300秒，间隔30秒。最后计算平均值。在测量每个配置（预热运行）之前，创建了一个daytrader数据库，其中有15000名用户。在配置度量的每次迭代之前，数据库都被重置。

在负载下测试时，默认热点比OpenJ9消耗更多内存。但是，相同的-XX:SharedArchiveFile=app-cds。jsa和-XX:TieredStopAtLevel=1用于减少启动时间的参数提供了30%的占地面积减少。这是因为C1编译器在代码缓存中使用的内存较少，因为编译后的代码没有额外的中间表达式。由于不同JVM共享的公共类元数据，AppCDS最小化了占用空间。

测试配置：

• OpenJ9（1）（堆1G）：“-Xmx1G”
• OpenJ9（2）（堆1G，类缓存）：“-Xmx1G-Xshareclasses:name=mvn”
• OpenJ9（3）（堆1G，类缓存，快速编译）：“-Xmx1G-Xshareclasses:name=mvn-Xtune:virtualized-Xscmx200m”
• HotSpot（堆1G）：“-Xmx1G”
• HotSpot（堆1G，AppCDS，C1）：“-Xmx1G-XX:SharedArchiveFile=app-cds.jsa-XX:TieredStopAtLevel=1”

测试计划包括执行复杂操作的各种查询的组合。图表上的红点表示启动时间。最大堆大小设置为256 MB（Xmx256m标志）。指标是在~126秒时测量的。选择该点是因为不同的热点和OpenJ9配置具有不同的启动时间。应用程序启动后，内存消耗会因负载而增加，然后趋于稳定。正如您在图中所注意到的，OpenJ9在稳定之前展示了内存消耗的飞跃。这是预热所需的内存，这可能会成为一个问题，因为应用程序在稳定状态下消耗的内存比我们预期的要多。因此，如果我们在预热后将内存限制设置为应用程序所需，稳定时间可能会增加，峰值性能会下降。

就leaps而言，它们值得单独研究优化策略。例如，Liberica Lite是我们的LibericaJDK的轻量级版本，它可以为未加载的工作流释放内存，OpenJ9最近收到了JIT作为服务，这使虚拟机能够将多个实例的峰值内存消耗转移到一个编译服务中。

此外，Liberica Lite支持创建微容器，以大幅减少资源消耗。这一指标对于云计算尤其有价值，因为在云计算中，小容器的成本效率相等。一个基于Liberica Lite和Alpine Linux的容器只有42.72MB-是目前市场上最小的！

回到我们的研究，我们的目标是评估稳定条件下的应用程序内存消耗。126秒后，所有虚拟机配置都显示出稳定值，可以测量。从图中可以看出，配置的热点等于或优于两种OpenJ9配置。

延迟和吞吐量

在这组实验中，最大堆大小设置为1 GB（-Xmx1G）。这样，我们可以在一个典型的小型云节点的范围内分析应用程序的行为。

默认热点配置显示了最佳吞吐量（比最佳OpenJ9配置高5%）和延迟（比最佳OpenJ9配置低69%），但在内存消耗方面落后于OpenJ9。-XX:SharedArchiveFile=app-cds.jsa -XX:TieredStopAtLevel=1标志优化了占用指标，但不影响吞吐量和延迟。然而，HotSpot有很多垃圾收集器可供选择，我们可以使用最适合我们的垃圾收集器。在这里，我们切换到串行垃圾收集器（-XX:+UseSerialGC参数），提供了较少的开销。串行GC是最简单的垃圾收集器实现，它只使用一个线程，因此减少了线程开销。它最适用于单处理器机器或具有小堆的应用程序。

此外，为了减少占用空间，我们将InitialHeapSize设置为80MB（Xms80m标志）。

测试配置：

• OpenJ9（1）（堆1G）：“-Xmx1G”
• OpenJ9（2）（堆1G，类缓存）：“-Xmx1G-Xshareclasses:name=mvn”
• OpenJ9（3）（堆1G，类缓存，快速编译）：“-Xmx1G-Xshareclasses:name=mvn-Xtune:virtualized-Xscmx200m”
• HotSpot（最大堆1G，初始堆80MB）：“-Xmx1G-Xms80m”
• HotSpot（最大堆1G，初始堆80MB，AppCDS，C1）：“-Xmx1G-Xms80m-XX:SharedArchiveFile=app-cds.jsa-XX:TieredStopAtLevel=1”
• HotSpot（最大堆1G，初始堆80MB，SerialGC）：“-Xmx1G-Xms80m-XX:SharedArchiveFile=app-cds.jsa-XX:TieredStopAtLevel=1-XX:+UseSerialGC”

这些指标的测量值约为99.998%。从图中可以看出，默认的热点配置具有最好的指标之一，排名前三（lib-def-xms80m），但结果为-XX:SharedArchiveFile=app-cds.jsa -XX:TieredStopAtLevel=1参数正好相反（lib-xms80m）。尽管如此，即使这种配置也比OpenJ9（1）具有更低的延迟，这显示了最糟糕的结果。然而，具有串行GC的热点（lib-xms80m-SerialGC）在延迟和内存方面显示了最佳结果。

上图显示，G1的默认热点具有最佳吞吐量，但留下了更大的空间。您可以选择使用串行GC或AppCD的配置，以关注更好的延迟或内存占用指标。您还可以使用并行GC，它使用多个线程来加速垃圾收集器，并有助于提高吞吐量。

结论

在所有测试平台上的实验结果相似，并证明配置了HotSpot的Liberica JDK与OpenJ9相当或优于OpenJ9。值得注意的是，在服务器级节点上，默认HotSpot比OpenJ9具有更低的延迟和更高的吞吐量，这有利于长期降低成本。同时，通过切换到另一个VM映像（Alpine Linux使用的RAM是CentOS的两倍）或在项目中引入本机映像技术，可以最小化此配置留下的大量内存占用。