"Field too big for insn" error building on Apple M1

[graalvm]

"Field too big for insn" error building on Apple M1

[galderz]

Yeah that worked, thx @lewurm :)

[galderz]

To be more precise about the failures, they happen when executing jmod of the built JDK, e.g. :

❯ more support_interim-jmods_support__create_java.logging.jmod_exec.cmdline
/opt/labs-openjdk-17/build/labsjdk/buildjdk/jdk/bin/jmod -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 create --module-version 17.0.3 --target-platform 'macos-aarch64' --module-path /opt/labs-openjdk-17/build/labsjdk/support/interim-jmods --config /opt/labs-openjdk-17/build/labsjdk/buildjdk/support/modules_conf/java.logging --class-path /opt/labs-openjdk-17/build/labsjdk/buildjdk/jdk/modules/java.logging --legal-notices "/opt/labs-openjdk-17/build/labsjdk/buildjdk/support/modules_legal/common" --exclude '**{_the.*,_*.marker*,*.diz,*.debuginfo,*.dSYM/**,*.dSYM}' /opt/labs-openjdk-17/build/labsjdk/support/interim-jmods/support/java.logging.jmod

❯ more support_interim-jmods_support__create_java.logging.jmod_exec.log
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (assembler_aarch64.hpp:248), pid=56929, tid=10243
#  guarantee(val < (1ULL << nbits)) failed: Field too big for insn
#
# JRE version:  (17.0.3) (build )
# Java VM: OpenJDK 64-Bit Server VM (17.0.3+0-jvmci-22.1-b05, mixed mode, emulated-client, sharing, tiered, compressed oops, compressed class ptrs, serial gc, bsd-aarch64)
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /opt/labs-openjdk-17/make/hs_err_pid56929.log
#
#
...

[lewurm]

I can't reproduce it. The only difference I've spotted so far is that you are using Xcode 13.3 while I'm using Xcode 13.2.1. I'll try it with 13.3 as well (but it takes some while to obtain it with my landline 🙄 ).

The boot JDK is a locally build of jdk17u-dev, which built fine on M1 [...]

When did you build that? That assert in assembler_aarch64.hpp is the same as in jdk17u-dev. The stack trace shows that this assert hits pretty early in the startup when emitting the stubs, so you should see the same issue on jdk17u-dev for sure (with a newer Xcode, if that is the problem).

[lewurm]

It's indeed an issue exposed by a clang update, the fix landed in jdk17u-dev: openjdk/jdk17u-dev@fbe05ec
But we don't have it in our tree yet.

Does that fix works for you @galderz?

[galderz]

Thx @lewurm for the insights. I'll cherry pick the commit and see if that works.