Repository navigation
jvm ladder on aarch64 - #910
Draft
bryan-minimal wants to merge 9 commits into
Draft
bryan-minimal wants to merge 9 commits into
bryan-minimal wants to merge 9 commits into
Conversation
The first three rungs get an aarch64 spec next to the x86_64 one, which is unchanged (same spec hashes). On aarch64 each builds with the toolchain gcc against the system glibc through build-aarch64.sh, derived from build.sh: SR=/usr and the system loader instead of the bedrock sysroot, no per-process loader wrappers, and config.sub / config.guess refreshed from automake (the tarballs predate aarch64). JamVM has no aarch64 port upstream; jamvm-1.5.1 applies Simon South's (2020, carried by Guix) and regenerates its build system. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: true
Comment |
…vm-2.0.0, ecj4 Same treatment as the first three rungs (x86_64 spec hashes unchanged). jamvm-2.0.0 adds Simon South's aarch64 port ahead of the two Guix fixes it already carries, and regenerates its build system. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
icedtea-7's HotSpot drop already carries the AArch64 port; aarch64 adds Guix's c++98 patch for sharedRuntime_aarch64.cpp. icedtea-8 drops the duplicate call_VM_leaf_base using-declaration in interp_masm_aarch64.hpp that gcc 11+ rejects (Guix's patch-for-aarch64). x86_64 specs unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Same treatment as the earlier rungs (x86_64 spec hashes unchanged, checked for all 17). OpenJDK knows aarch64, so no config.sub refresh; each aarch64 build drops the duplicate call_VM_leaf_base using-declaration in interp_masm_aarch64.hpp where a release has it (gcc 11+ rejects it; Guix's patch-for-aarch64). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ieeefp.h predates aarch64 and fails with 'Endianess not declared'; classpath-0.93/0.99/devel add the __aarch64__ case on aarch64 (Guix's classpath-aarch64-support.patch, inserted with python3 since the rungs carry no patch tool). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
glibc 2.42+ declares uabs(int) in <stdlib.h>, which collides with HotSpot's own overloads in the aarch64 build; rename them to hs_uabs as icedtea-8 already does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On aarch64 the bundled libpng enables its ARM NEON paths, but the JDK build never compiles libpng's neon sources, so libsplashscreen fails to link (png_init_filter_functions_neon). Prepend PNG_ARM_NEON_OPT=0 to every bundled pngpriv.h in icedtea-7/8 and openjdk-9..25 on aarch64. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The x86_64 recipes pin the boot JVM to AVX2 against an AVX-512 miscompile; the option does not exist on aarch64, so every java step of the build failed. Drop it from the aarch64 recipes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
mip check --fix; spec hashes unchanged on both arches. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked r
2ECE
esolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Brings the whole JVM bootstrap ladder to aarch64: jikes → classpath-0.93 → jamvm-1.5.1 → ant/ecj → classpath-0.99/devel → jamvm-2.0.0 → ecj4 → icedtea-7 → icedtea-8 → openjdk-9 … 25. That is all 28 rungs.
mip dumpfor all 28). The aarch64 recipe lives in a separatebuild-aarch64.sh, selected bycmd, so arm iterations never rebuild amd64.toolchaingcc (hex0-rooted) against the system glibc.build-aarch64.shis derived mechanically frombuild.sh:SR=/usr, the system loader/usr/lib/ld-linux-aarch64.so.1, and no bedrock loader wrappers. The pre-OpenJDK tarballs getconfig.sub/config.guessrefreshed from automake, because they predate aarch64.autoreconf.call_VM_leaf_baseduplicate-declaration fix ininterp_masm_aarch64.hpp, applied only where a release has the duplicate.Not in scope:
packages/jdk(still the Temurin bindist on both arches).Result
All 28 rungs build on aarch64 in the sandbox. Runs on
15749809andc2eaa8cb: every rung uploaded with signed provenance, and package checks passed with 0 failures. The arm openjdk-25 artifact is 149 MB zstd (sha25675fff8fc…).aarch64-only fixes found along the way, on top of the ports above:
ieeefp.hgets an__aarch64__endianness case.uabsis renamed tohs_uabs, because glibc 2.42+ declaresuabs.PNG_ARM_NEON_OPT=0, because the JDK build never compiles libpng's NEON sources.-XX:UseAVX=2. It is an x86-only workaround, and the aarch64 JVM rejects the option.🤖 Generated with Claude Code