JDK-8323273 : AArch64: Strengthen CompressedClassPointers initialization check for base
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 23
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • CPU: aarch64
  • Submitted: 2024-01-09
  • Updated: 2024-10-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Description
This bugid is trying to address two issues, which should be able to be solved by installing additional checks for the base address of CompressedClassPointers during initialization.

First, using CompressedClassSpaceBaseAddress with an address over 4g and not aligned to 4g will cause a crash on debug build:
$./build/linux-aarch64-server-fastdebug/images/jdk/bin/java -Xshare:off -XX:CompressedClassSpaceBaseAddress=50g -version
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/yude.lyd/yude.lyd/jdk-master2/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:4675), pid=36060, tid=36062
#  guarantee((shifted_base & 0xffff0000ffffffff) == 0) failed: compressed class base bad alignment
#
# JRE version:  (23.0) (fastdebug build )
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.yudelyd.jdk-master2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x121b9e0]  MacroAssembler::klass_decode_mode()+0x228
#
# 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:
# /mnt/yude.lyd/jdk-master2/hs_err_pid36060.log
#
#
Aborted

Secondly, there is this path in Metaspace::reserve_address_space_for_compressed_classes that might lead to similar crashes in release build if we are incredibly unlucky:
```
  NOT_ZERO(result =
      (char*) CompressedKlassPointers::reserve_address_space_for_compressed_classes(size, RandomizeClassSpaceLocation,
                                                                                    optimize_for_zero_base));

  if (result == nullptr) {
    // Fallback: reserve anywhere
    log_debug(metaspace, map)("Trying anywhere...");
    result = os::reserve_memory_aligned(size, Metaspace::reserve_alignment(), false);
  }
```
If the first reserve function fails, the second reserve function comes in, which disregards some important constraints on aarch64 (4g alignment etc.)
(The first reserve function could fail due to aslr. Not that I have observed a failure.)
Comments
As discussed in the review thread https://github.com/openjdk/jdk/pull/17437 , we will hold until the Lilliput change https://bugs.openjdk.org/browse/JDK-8325104 is in. We will work from there if we still find it necessary at that point, and if it's simple enough to implement.
20-02-2024

Neither of those are bugs; both work as designed. - CompressedClassSpaceBaseAddress is supposed to use any address as base, including invalid addresses, without being smart about it. Its purpose is to test the JVMs response to that address. If that response is asserting on some platform, that's what it should do. It is a debug-only tool only used for tests. - The "reserve anywhere" path at the end of class space allocation ends a long chain of allocation attempts (first 32 randomized allocation attempts at preferred addresses; followed by a properly 4G aligned allocation attempt via mmap over-allocation). The chance to end up here is very slim. However, if we *do* end up here, attempting another mmap does not harm since it may succeed even if the chances are slim. There is no need to increase complexity unnecessarily by re-adding arm64-specific code sections
19-02-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/17437 Date: 2024-01-16 02:41:40 +0000
16-01-2024