JDK-8321619 : Generational ZGC: ZColorStoreGoodOopClosure is only valid for young objects
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 21,22,23
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-12-08
  • Updated: 2024-02-15
  • Resolved: 2023-12-19
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 22Fixed 23 b03Fixed
Related Reports
Relates :  
JDK-8325074 - ZGC fails assert(index == 0 || is_power_of_2(index)) failed: Incorrect load shift: 11
Relates :  
JDK-8324223 - J2dBench-vimg_copyarea regressions after JDK-8321619
Description
The recently added test java/lang/String/CompactString/NegativeSize test failed with:

failed: ZColorStoreGoodOopClosure is only valid for young objects

The test creates several maximum size byte arrays.

#  assert(ZHeap::heap()->is_young(to_zaddress(dst))) failed: ZColorStoreGoodOopClosure is only valid for young objects
#
# JRE version: Java(TM) SE Runtime Environment (22.0+27) (fastdebug build 22-ea+27-2244)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-ea+27-2244, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1013233]  AccessInternal::PostRuntimeDispatch<ZBarrierSet::AccessBarrier<270400ul, ZBarrierSet>, (AccessInternal::BarrierType)9, 270400ul>::access_barrier(oop, oop, unsigned long)+0x2a3
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/138 Date: 2024-01-08 09:32:06 +0000
08-01-2024
[jdk21u-fix-request] Approval Request from Aleksey Shipilëv Clean backport to fix Generational ZGC. Applies cleanly. Light testing passes.
08-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk22/pull/20 Date: 2023-12-19 14:07:48 +0000
19-12-2023
Changeset: be49dabd Author: Erik Österlund <eosterlund@openjdk.org> Date: 2023-12-19 13:49:01 +0000 URL: https://git.openjdk.org/jdk/commit/be49dabd0d7e1cd270399849e5353bf33361c4c5
19-12-2023
Thanks for noticing that [~gli] - I fixed it.
19-12-2023
The mainline is at 23 now. It is good to change the `fix version` to 23 and then backport to 22 after integrating. If we keep the `fix version` as 22, the bot will create a backport issue unexpectedly when integrating.
19-12-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/17141 Date: 2023-12-18 12:51:34 +0000
18-12-2023
The assert is a false positive. It tries to detect if we needed stronger barriers than we used, which is a concern for large object arrays that can get promoted to the old generation before they are fully initialized due to incremental safepoint polling in the initialization code. However, this test clearly allocates a large string where the array doesn't contain any oops, so there is no problem here. Moreover, the code now always uses a store barrier, not just colouring. Having said that, I believe there is a real bug here anyway. If the source array was to be a large object array and we are cloning from the interpreter or C1 (C2 intrinsifies this pattern to an optimized allocation followed by arraycopy), and after the allocation but before the copy, a concurrent thread writes a bunch of values across the source array, the copied payload in the destination will not recognize the need for store barriers to log remembered set entries, which could potentially yield a crash some time further down the line. This would require a lot of stars to align, but seems in theory rather possible.
12-12-2023