Graal JIT 编译器操作手册

测量性能 #

衡量性能时首先要确认的是 Java 虚拟机 (JVM) 正在使用 Graal JIT 编译器。

GraalVM 默认配置为使用 Graal JIT 编译器作为顶级编译器。

要在 Java HotSpot 虚拟机中使用 Graal JIT 编译器,请使用 -XX:+UseGraalJIT 选项。(-XX:+UseGraalJIT 选项必须与 -XX:+UnlockExperimentalVMOptions 选项一起使用,后者用于解锁此实验性集成。)

以下示例运行 Java 应用程序 com.example.myapp,并启用 Graal JIT 编译器。

java -XX:+UnlockExperimentalVMOptions -XX:+UseGraalJIT com.example.myapp

您可以通过向命令行添加 -Djdk.graal.ShowConfiguration=info 选项来确认是否正在使用 Graal JIT 编译器。当编译器初始化时,它会生成一行类似于以下内容的输出:

Using "Graal Enterprise compiler with Truffle extensions" loaded from a PGO optimized Native Image shared library

注意:Graal 编译器仅在首次顶级 JIT 编译请求时初始化,因此如果您的应用程序生命周期较短,您可能看不到此输出。

优化基于 JVM 的应用程序本身就是一门学问。在性能不佳的情况下,编译甚至可能不是影响因素,因为问题可能出在 JVM 的任何其他部分(I/O、垃圾收集、线程等),或者出在编写不佳的应用程序或第三方库代码中。因此,值得使用 JDK Mission Control 工具链来诊断应用程序的行为。

您还可以通过向命令行添加 -XX:-UseJVMCICompiler 来将性能与 JVM 中的原生顶级编译器进行比较。

如果您在使用 Graal JIT 编译器时观察到明显的性能下降,请在 GitHub 上提出问题。附上 Java Flight Recorder 日志和重现问题的说明——这会使调查更容易,从而增加修复的可能性。更好的是,如果您能提交一个 JMH 基准测试,它代表了您应用程序中最热的部分(由分析器识别)。这使我们能够快速查明缺失的优化机会,或提供有关如何重构代码以避免或减少性能瓶颈的建议。

Graal JIT 编译器故障排除 #

如果您发现安全漏洞,请不要通过 GitHub Issues 或公共邮件列表报告,而是通过 漏洞报告指南 中概述的流程报告。

编译异常 #

编译器用 Java 编写的一个优点是,编译期间的 Java 异常不是致命的 JVM 错误。相反,每次编译都有一个异常处理程序,它根据 graal.CompilationFailureAction 属性采取行动。

默认值为 Silent。如果指定 Diagnose,失败的编译将使用额外的诊断信息进行重试。在这种情况下,就在 JVM 退出之前,重试编译期间捕获的所有诊断输出将写入一个 ZIP 文件,其位置将打印在控制台上,例如:

Graal diagnostic output saved in /Users/demo/graal-dumps/1499768882600/graal_diagnostics_64565.zip

然后,您可以将该 ZIP 文件附加到 GitHub 上的问题中。

除了 SilentDiagnosegraal.CompilationFailureAction 还有以下可用值:

  • Print:向控制台打印消息和堆栈跟踪,但不执行重新编译。
  • ExitVM:与 Diagnose 相同,但 JVM 进程在重新编译后退出。

代码生成错误 #

您可能遇到的另一种编译器错误是生成不正确的机器代码。此错误可能导致 JVM 崩溃,并在 JVM 进程的当前工作目录中生成一个以 hs_err_pid 开头的文件。在大多数情况下,文件中有一个部分显示了崩溃时的堆栈,包括堆栈中每个帧的代码类型,如下例所示:

Stack: [0x00007000020b1000,0x00007000021b1000],  sp=0x00007000021af7a0,  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 761 JVMCI jdk.graal.compiler.core.gen.NodeLIRBuilder.matchComplexExpressions(Ljava/util/List;)V (299 bytes) @ 0x0000000108a2fc01 [0x0000000108a2fac0+0x141] (null)
j  jdk.graal.compiler.core.gen.NodeLIRBuilder.doBlock(Ljdk.graal.compiler/nodes/cfg/Block;Ljdk.graal.compiler/nodes/StructuredGraph;Ljdk.graal.compiler/core/common/cfg/BlockMap;)V+211
j  jdk.graal.compiler.core.LIRGenerationPhase.emitBlock(Ljdk.graal.compiler/nodes/spi/NodeLIRBuilderTool;Ljdk.graal.compiler/lir/gen/LIRGenerationResult;Ljdk.graal.compiler/nodes/cfg/Block;Ljdk.graal.compiler/nodes/StructuredGraph;Ljdk.graal.compiler/core/common/cfg/BlockMap;)V+65

此示例显示,顶层帧由 JVMCI 编译器(即 Graal JIT 编译器)编译 (J)。崩溃发生在为以下内容生成的机器代码的偏移量 0x141 处:

jdk.graal.compiler.core.gen.NodeLIRBuilder.matchComplexExpressions(Ljava/util/List;)V

堆栈中的接下来的两个帧被解释 (j)。崩溃位置也经常在文件顶部附近通过类似以下内容指示:

# Problematic frame:
# J 761 JVMCI jdk.graal.compiler.core.gen.NodeLIRBuilder.matchComplexExpressions(Ljava/util/List;)V (299 bytes) @ 0x0000000108a2fc01 [0x0000000108a2fac0+0x141] (null)

在此示例中,Graal JIT 编译器为 NodeLIRBuilder.matchComplexExpressions 生成的代码可能存在错误。

当在 GitHub 上提交此类崩溃的问题时,您应该首先尝试在对问题方法编译启用额外诊断的情况下重现崩溃。在此示例中,您可以将以下选项添加到命令行:

-Djdk.graal.MethodFilter=NodeLIRBuilder.matchComplexExpressions, -Djdk.graal.Dump=:2

这些选项在 编译器调试文档 中有更详细的描述。简而言之,这些选项指示 Graal JIT 编译器在编译类简称为 NodeLIRBuilder 中名为 matchComplexExpressions 的任何方法时,以详细程度级别 2 捕获其状态快照。MethodFilter 选项的完整格式在 MethodFilterHelp.txt 中有描述。

通常,崩溃位置并非直接存在于崩溃日志中提到的问题方法中,而是来自内联方法。

在这种情况下,仅仅过滤问题方法可能无法捕获导致崩溃的错误编译。

为了提高捕获错误编译的可能性,请扩大 MethodFilter 值。为此,在尝试重现崩溃时添加 -Djdk.graal.PrintCompilation=true 选项,以便您可以看到崩溃前编译了什么。

以下显示了控制台的示例输出:

HotSpotCompilation-1218        Ljdk.graal.compiler/core/amd64/AMD64NodeLIRBuilder;                  peephole                                      (Ljdk.graal.compiler/nodes/ValueNode;)Z           |   87ms   428B   447B  1834kB
HotSpotCompilation-1212        Ljdk.graal.compiler/lir/LIRInstructionClass;                         forEachState                                  (Ljdk.graal.compiler/lir/LIRInstruction;Ljdk.graal.compiler/lir/InstructionValueProcedure;)V  |  359ms    92B   309B  6609kB
HotSpotCompilation-1221        Ljdk.graal.compiler/hotspot/amd64/AMD64HotSpotLIRGenerator;          getResult                                     ()Ljdk.graal.compiler/hotspot/HotSpotLIRGenerationResult;  |   54ms    18B   142B  1025kB
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000010a6cafb1, pid=89745, tid=0x0000000000004b03
#
# JRE version: OpenJDK Runtime Environment (8.0_121-b13) (build 1.8.0_121-graalvm-olabs-b13)
# Java VM: OpenJDK 64-Bit GraalVM (25.71-b01-internal-jvmci-0.30 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# J 1221 JVMCI jdk.graal.compiler.hotspot.amd64.AMD64HotSpotLIRGenerator.getResult()Ljdk.graal.compiler/hotspot/HotSpotLIRGenerationResult; (18 bytes) @ 0x000000010a6cafb1 [0x000000010a6caf60+0x51] (null)
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

这里,崩溃发生在与第一次崩溃不同的方法中。因此,我们将过滤参数扩展为 -Djdk.graal.MethodFilter=NodeLIRBuilder.matchComplexExpressions,AMD64HotSpotLIRGenerator.getResult 并再次运行。

当 JVM 以这种方式崩溃时,它不会运行用于归档 Graal 编译器诊断输出或删除写入目录的关闭代码。这必须在崩溃后手动完成。

默认情况下,目录是 $PWD/graal-dumps/<timestamp>(例如,./graal-dumps/1499938817387)。但是,您可以使用 -Djdk.graal.DumpPath=<path> 选项指定目录。

当编译器首次使用此目录时,控制台会打印出如下消息:

Dumping debug output in /Users/demo/graal-dumps/1499768882600

此目录应包含与崩溃方法相关的内容,例如:

ls -l /Users/demo/graal-dumps/1499768882600
-rw-r--r--  1 demo  staff    144384 Jul 13 11:46 HotSpotCompilation-1162[AMD64HotSpotLIRGenerator.getResult()].bgv
-rw-r--r--  1 demo  staff     96925 Jul 13 11:46 HotSpotCompilation-1162[AMD64HotSpotLIRGenerator.getResult()].cfg
-rw-r--r--  1 demo  staff  12600725 Jul 13 11:46 HotSpotCompilation-791[NodeLIRBuilder.matchComplexExpressions(List)].bgv
-rw-r--r--  1 demo  staff   1727409 Jul 13 11:46 HotSpotCompilation-791[NodeLIRBuilder.matchComplexExpressions(List)].cfg

您应该将此目录的 ZIP 文件附加到 GitHub 上的问题中。

联系我们