On Wed, 17 Dec 2025 09:40:00 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. lgtm. Thanks for fixing. ------------- Marked as reviewed by aboldtch (no project role). PR Review: https://git.openjdk.org/valhalla/pull/1811#pullrequestreview-3586875976
