JDK-8312749 : Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index))
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 21,22
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2023-07-25
  • Updated: 2023-12-11
  • Resolved: 2023-08-25
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.
JDK 22
22 b13Fixed
Related Reports
Cloners :  
JDK-8315082 - [REDO] Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index))
Relates :  
JDK-8307058 - Implementation of Generational ZGC
Relates :  
JDK-8315029 - [BACKOUT] Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index))
Relates :  
JDK-8314994 - C2: simplify the array cloning intrinsic implementation
Sub Tasks
JDK-8314018 :  
Release Note: JVM May Crash or Malfunction When Using ZGC and Non-Default ObjectAlignmentInBytes - Resolved
Description
Tests:
compiler/unsafe/GetUnsafeObjectG1PreBarrier.java
compiler/c2/TestNPEHeapBased.java
java/lang/instrument/GetObjectSizeIntrinsicsTest.java#id7
java/lang/instrument/GetObjectSizeIntrinsicsTest.java#id6

Product tested: JDK-21.0.1+2 (ATR run), regression happening from jdk-21+23
OS/architecture: Linux-x64-debug, not seen in product build
Reproducible: Always with below jvm-args
Is it a Regression: yes, started from  jdk-21+23 with the introduction of ZGenerational ZGC
Is it a platform-specific issue: Not sure, currently seen only with linux-x64-debug.


Error:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S75332/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/9f54ee97-f028-4eeb-8d9f-e71282916f83/runs/7a6c13e7-18c4-47c0-803f-9564e908be6a/workspace/open/src/hotspot/cpu/x86/gc/z/zAddress_x86.inline.hpp:35), pid=2718529, tid=2718532
#  assert(index == 0 || is_power_of_2(index)) failed: Incorrect load shift: 11
#
# JRE version: Java(TM) SE Runtime Environment (21.0.1+2) (fastdebug build 21.0.1-ea+2-LTS-6)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21.0.1-ea+2-LTS-6, compiled mode, tiered, compressed class ptrs, z gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x5f0841]  ZPointer::load_shift_lookup(unsigned long)+0x61
#
# Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S75487/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b5a7a9b7-646f-4048-af4e-631e65e44fe7/runs/511c385e-5ad4-464a-81d8-dea39b7f0e83/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_compiler_all_gcs/scratch/4/core.2718529)
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
Comments
Will back out this issue and create a redo that addresses the failures reported in JDK-8315029.
28-08-2023
Changeset: 002b5948 Author: Roberto Castañeda Lozano <rcastanedalo@openjdk.org> Date: 2023-08-25 07:18:34 +0000 URL: https://git.openjdk.org/jdk/commit/002b59487094f98d9805997b5d1122c1a411b391
25-08-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/15288 Date: 2023-08-15 12:43:56 +0000
17-08-2023
This is an attempt to fix the bug. I'm leaving it here for those more well-versed in the compilers to take a look at: https://github.com/openjdk/jdk/compare/master...stefank:jdk:8312749_object_alignment_in_clone Run with and without -XX:+UseNewCode
04-08-2023
ILW = Crash in GC because load barrier is applied to uninitialized memory, old issue but only manifests with Generational ZGC and -XX:ObjectAlignmentInBytes=16, disable clone intrinsic or compilation of affected method = HLM = P3
03-08-2023
The assert already fails with the initial commit for Generational ZGC (JDK-8307058).
03-08-2023
The issue can be simply reproduced on latest mainline (commit ec2f38fd) using an empty Java source file as follows: $ touch Foo.java $ java -Xcomp -XX:+UseZGC -XX:+ZGenerational -XX:ObjectAlignmentInBytes=16 -XX:CompileOnly=java.lang.invoke.LambdaForm\$Name::replaceNames Foo.java
02-08-2023
Me and [~stefank] had a look in rr and could see that essentially an object cloning operation is being performed on an object array. It manifests when the object alignment is above 8 bytes. Then the C2 code is generating an arraycopy where the size to copy is based on the size of the allocation. But the allocation size is larger than the object size, because of the extra padding due to the inflated object alignment. The implication of this is that the arraycopy is performed out of bounds. Usually this doesn't matter because the source bytes are just copied into the replica. However, with Generational ZGC, we apply load barriers on this memory that is out of bounds, and hence uninitialized garbage. In particular, the clone intrinsic (cf. LibraryCallKit::inline_native_clone) calls the GraphKit::new_array method, which returns a too high array size due to padding, which is used to copy_to_clone() bytes *including* padding, which is uninitialized memory.
01-08-2023