JDK-8325074 : ZGC fails assert(index == 0 || is_power_of_2(index)) failed: Incorrect load shift: 11
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 21.0.3,22,23
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2024-01-31
  • Updated: 2024-07-03
  • Resolved: 2024-02-16
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 21 JDK 22 JDK 23
21.0.3Fixed 22.0.1Fixed 23 b11Fixed
Related Reports
Relates :  
Relates :  
Sub Tasks
JDK-8325875 :  
Description
The following test failed in the JDK23 CI:

compiler/gcbarriers/TestArrayCopyWithLargeObjectAlignment.java

Here's a snippet from the log file:

#section:main
----------messages:(6/665)----------
command: main -Xbatch -XX:-TieredCompilation -XX:CompileOnly=compiler.gcbarriers.TestArrayCopyWithLargeObjectAlignment::* -XX:ObjectAlignmentInBytes=16 -XX:+UseZGC -XX:+ZGenerational compiler.gcbarriers.TestArrayCopyWithLargeObjectAlignment
reason: User specified action: run main/othervm -Xbatch -XX:-TieredCompilation -XX:CompileOnly=compiler.gcbarriers.TestArrayCopyWithLargeObjectAlignment::* -XX:ObjectAlignmentInBytes=16 -XX:+UseZGC -XX:+ZGenerational compiler.gcbarriers.TestArrayCopyWithLargeObjectAlignment 
started: Wed Jan 31 20:11:37 UTC 2024
Mode: othervm [/othervm specified]
finished: Wed Jan 31 20:11:41 UTC 2024
elapsed time (seconds): 4.226
----------configuration:(0/0)----------
----------System.out:(18/1175)*----------
CompileCommand: compileonly compiler/gcbarriers/TestArrayCopyWithLargeObjectAlignment.* bool compileonly = true
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (c:\\sb\\prod\\1706638844\\workspace\\open\\src\\hotspot\\cpu\\x86\\gc/z/zAddress_x86.inline.hpp:35), pid=43684, tid=21492
#  assert(index == 0 || is_power_of_2(index)) failed: Incorrect load shift: 11
#
# JRE version: Java(TM) SE Runtime Environment (23.0+8) (fastdebug build 23-ea+8-532)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 23-ea+8-532, compiled mode, compressed class ptrs, z gc, windows-amd64)
# Core dump will be written. Default location: C:\\sb\\prod\\1706731244\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_tier1_compiler_2\\scratch\\1\\hs_err_pid43684.mdmp
#
# An error report file with more information is saved as:
# C:\\sb\\prod\\1706731244\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_tier1_compiler_2\\scratch\\1\\hs_err_pid43684.log
[0.742s][warning][os] Loading hsdis library failed
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
----------System.err:(0/0)----------
----------rerun:(54/6331)*----------

Here's the crashing thread's stack:

---------------  T H R E A D  ---------------

Current thread (0x00000167782d4fa0):  JavaThread "MainThread"        [_thread_in_vm, id=21492, stack(0x0000003d65600000,0x0000003d65700000) (1024K)]

Stack: [0x0000003d65600000,0x0000003d65700000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xc97981]  os::win32::platform_print_native_stack+0x101  (os_windows_x86.cpp:236)
V  [jvm.dll+0xf3dffb]  VMError::report+0x149b  (vmError.cpp:1006)
V  [jvm.dll+0xf406be]  VMError::report_and_die+0x80e  (vmError.cpp:1841)
V  [jvm.dll+0xf40de4]  VMError::report_and_die+0x64  (vmError.cpp:1606)
V  [jvm.dll+0x55230b]  report_vm_error+0x5b  (debug.cpp:191)
V  [jvm.dll+0x1904d]  ZPointer::uncolor_unsafe+0xfd  (zAddress.inline.hpp:454)
V  [jvm.dll+0x184cb]  ZBarrier::make_load_good+0x11b  (zBarrier.inline.hpp:307)
V  [jvm.dll+0xfe0330]  ZBarrierSet::clone_obj_array+0x140  (zBarrierSet.cpp:160)
V  [jvm.dll+0x8e8f51]  ZBarrierSet::AccessBarrier<270400,ZBarrierSet>::clone_in_heap+0xf1  (zBarrierSet.inline.hpp:443)
V  [jvm.dll+0x8e87aa]  AccessInternal::PostRuntimeDispatch<ZBarrierSet::AccessBarrier<270400,ZBarrierSet>,9,270400>::access_barrier+0x9a  (access.inline.hpp:200)
V  [jvm.dll+0x8e8ca6]  Access<262144>::clone+0x1e6  (access.hpp:211)
V  [jvm.dll+0x8f1511]  JVM_Clone+0x631  (jvm.cpp:698)
C  0x0000016371b8e9b6  (no source info available)

The last pc belongs to native method entry point (kind = native) (printed below).
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  java.lang.Object.clone()Ljava/lang/Object;+0 java.base@23-ea
j  compiler.gcbarriers.TestArrayCopyWithLargeObjectAlignment.doClone([Ljava/lang/Object;)[Ljava/lang/Object;+1
j  compiler.gcbarriers.TestArrayCopyWithLargeObjectAlignment.main([Ljava/lang/String;)V+30
j  java.lang.invoke.LambdaForm$DMH+0x00000000370c0800.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base@23-ea
j  java.lang.invoke.LambdaForm$MH+0x00000000370c1c00.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base@23-ea
j  java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base@23-ea
j  jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base@23-ea
j  jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base@23-ea
j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base@23-ea
j  com.sun.javatest.regtest.agent.MainWrapper$MainTask.run()V+134
j  java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@23-ea
j  java.lang.Thread.run()V+19 java.base@23-ea
v  ~StubRoutines::call_stub 0x0000016371b8106f
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jdk22u/pull/66 Date: 2024-02-23 06:10:54 +0000
23-02-2024

[jdk21u-fix-request] Approval Request from Aleksey Shipilëv Clean backport to fix a regression introduced by JDK-8321619 in 21.0.3. Only affects Generational ZGC (new in 21), all tests pass with some known failures.
19-02-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/268 Date: 2024-02-19 08:59:04 +0000
19-02-2024

Fix Request This fix is required to use non standard `ObjectAlignmentInBytes` with `-XX:+UseZGC -XX:+ZGenerational`.
16-02-2024

Changeset: 2705ed0a Author: Axel Boldt-Christmas <aboldtch@openjdk.org> Date: 2024-02-16 08:34:58 +0000 URL: https://git.openjdk.org/jdk/commit/2705ed0a71e606a517518569d60051c85ad3c516
16-02-2024

All right, so this fix should go to 21.0.3 too, noted.
15-02-2024

Thanks. You are right. JDK-8321619 is the cause of this issue. I've updated the link.
15-02-2024

The link to "backport of JDK-8321619" looks incorrect, or am I missing something?
15-02-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/17863 Date: 2024-02-15 07:08:50 +0000
15-02-2024

[~ryadav] - That's not really up to me. I don't work on the Compiler team.
01-02-2024

Hi Daniel, Can i start looking at it, if it's not already assigned?
01-02-2024

I've started this bug off in hotspot/gc for initial triage since it's crashing in ZGC code. However, this same assertion failure was previously seen in this bug: JDK-8315082 [REDO] Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) which was handled over in hotspot/compiler.
31-01-2024