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

[duke]

On Wed, 17 Dec 2025 16:22:05 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 two additional commits since the last revision:
> 
>  - Add test for large primitive only flat arrays
>  - Assert fixes

@jsikstro 
Your change (at version c35878c042bcb4648f412bb825c020c825528b59) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1811#issuecomment-3670943154