RFD: AOT for AArch64 (original) (raw)

Andrew Haley aph at redhat.com
Tue Mar 27 15:23:48 UTC 2018


On 27/03/18 16:08, Dmitry Chuyko wrote:

I manually applied 2 parts of the patch to graal sources from Andrew's repo: http://cr.openjdk.java.net/~aph/jaotc/jdk-hs-1/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Assembler.java.patch http://cr.openjdk.java.net/~aph/jaotc/jdk-hs-1/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64MacroAssembler.java.patch We use those built modules as a replacement for ones from JDK but the changes are not present in aarch64-branch-overflows.

What is this all about? I don't know what you've done or why.

Now java.base can be AOT'ed on machines we have. In the logs I see a lot (~37k) of failed compilations with a message like following:

Error: Failed compilation: com.sun.crypto.provider.GCMParameters.engineToString()Ljava/lang/String;: org.graalvm.compiler.graph.GraalGraphError: org.graalvm.compiler.debug.GraalError: Emitting code to load an object address is not currently supported on aarch64 at node: 2058|LoadConstantIndirectly

Interesting. I haven't seen that one.

Some methods fail to AOT because AOT compilation tries to initialize the classes, and some of the classes are inaccessible for security reasons. I'll look at rebasing to current Graal sources and push again.

-- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



More information about the hotspot-dev mailing list