On Wed, 17 Dec 2025 10:02:52 GMT, Joel Sikström <[email protected]> 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
