[lworld] RFR: 8373858: [lworld] Segmented clearing for flatArrays with no oops in ZGC [v2]

[Paul Hübner]

On Wed, 17 Dec 2025 10:02:52 GMT, Joel Sikström <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> ZGC optimizes initialization by performing segmented clearing for objArrays, which reduces time-to-safepoint. In the lworld branch, we currently opt out of segmented clearing if the objArray being initialized is a flatArray. This prevents us from taking advantage of shorter time-to-safepoints when the flatArray could be cleared in segments.
>> 
>> The main question is: which types of flatArrays should support segmented clearing? Since ZGC only supports 64-bit atomic operations, flatArrays containing oops are not possible without relying on internal-only features like loose-consistency and null-restriction. A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.
>> 
>> Given this, we are currently missing the opportunity to use segmented clearing for flatArrays that contain only primitive types, which we should add support for. Support for flatArrays containing oops can be considered in the future, once features like loose-consistency and null-restriction are available to the user. 
>> 
>> Testing:
>> * hotspot_valhalla, jdk_valhalla, tier1-4, with `-XX:+UseZGC`
>> 
>> * Some sanity testing in lldb to see if I get segmented clearing for any flatArrays, and I can see several flatArrays containing java/lang/Integer or java/lang/Character being cleared in segmentes.
>
> Joel Sikström has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Offline review feedback

src/hotspot/share/gc/z/zObjArrayAllocator.cpp line 64:

> 62:   }
> 63: 
> 64:   if (is_oop_containing_flat_array(_klass)) {

> A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.

Is this something we can guard against in the code as well? What happens if somebody creates a null-restricted non-atomic primitive-only flat array via the `ValueClass` API? Tearing from the user's POV is absolutely okay in such a case, but will any ZGC assumptions be violated?

src/hotspot/share/gc/z/zObjArrayAllocator.cpp line 87:

> 85:     oopDesc::release_set_mark(mem, _klass->prototype_header().set_marked());
> 86:   } else {
> 87:     if (EnableValhalla) {

FYI this will cause a merge conflict.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1811#discussion_r2626615251
PR Review Comment: https://git.openjdk.org/valhalla/pull/1811#discussion_r2626602012