These fixes address a series of failures reproducible when building arm32 natively on an arm32 platform (not cross-compilation), in both release and fastdebug modes.
1. jniFastGetField_arm.cpp: use offset_shift After JEP 401 was integrated, jfieldIDWorkaround's offset_shift changed from 2 to 3. ARM32 is the only port where the shift was hardcoded as the literal 2 in JNI_FastGetField::generate_fast_get_int_field0. Other architectures take this value from the jfieldIDWorkaround::offset_shift constant and picked up the change automatically. This caused java.io.FileDescriptor's int fd field to be read incorrectly in the native fdval() function (IOUtil.c, libnio.so), which made the JVM hang during module loading at the COMPILE_CREATE_SYMBOLS step of the JDK build (fd was incorrectly decoded as 0 -- a blocking read from stdin). Fix: use the jfieldIDWorkaround::offset_shift constant instead of the hardcoded literal. 2. oops/symbol.hpp: class alignas(8) Symbol JEP 401 widened VerificationType::TypeMask from 0x3 to 0x7, reserving a third bit for inline types. As a result is_reference() now requires a Symbol* to be 8-byte aligned. On 32-bit a Symbol sits at offset 4 inside a SymbolTable node, so is_reference() is always false and verification of any class fails with VerifyError. This only happens in release builds: in debug builds the node carries an extra DEBUG_ONLY field, which pushes the Symbol to offset 8. Fix: alignas(8) makes Symbol 8-byte aligned. On 64-bit the layout is unchanged. 3. make/autoconf/jdk-options.m4: disable cds-archive-preview for 32-bit systems The build unconditionally generates a preview CDS archive, but value objects are not supported on 32-bit: InlineKlass::InlineKlass hits assert "Should not be called in 32 bit mode" (markWord.hpp), and the jdk-image step fails while dumping classes_preview.jsa. Fix: make the cds-archive-preview option unavailable on non-64-bit platforms. 4. cds/archiveUtils.cpp: additional check for minimal gap size This fixes a fastdebug build failure at the generate-link-opt-data step: assert(is_aligned(gap_bytes(), SharedSpaceObjectAlignment)) failed. It is related to ee90f00b3b3 (8376822, UseCompactObjectHeaders: fill Klass alignment gaps), not to JEP 401. That change started inserting an alignment gap in front of a buffered Klass and recording it for later reuse. On arm32 the gap is always 4 bytes -- nothing can ever fit into it, and AllocGap fails its precondition. Fix: only record a gap that is at least SharedSpaceObjectAlignment. On 64-bit the gap is always a multiple of 8, so behaviour is unchanged. --------- - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). ------------- Commit messages: - 8390159: [ARM32] Native ARM32 build hangs in COMPILE_CREATE_SYMBOLS Changes: https://git.openjdk.org/jdk/pull/32402/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=32402&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8390159 Stats: 14 lines in 4 files changed: 8 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/32402.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/32402/head:pull/32402 PR: https://git.openjdk.org/jdk/pull/32402
