RFD: AOT for AArch64

Dmitry Chuyko dmitry.chuyko at bell-sw.com
Tue Mar 27 16:17:06 UTC 2018

On 03/27/2018 06:23 PM, Andrew Haley wrote:
> 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.
Your initial email contains command line for jaotc where --module-path 
and --upgrade-module-path point to jars built in forked Graal sources. I 
did so and got exactly the same exception when running jaotc.

>> 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.

More information about the hotspot-dev mailing list