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. ------------- Commit messages: - 8373858: [lworld] Segmented clearing for flatArrays with no oops in ZGC Changes: https://git.openjdk.org/valhalla/pull/1811/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1811&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373858 Stats: 15 lines in 1 file changed: 13 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1811.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1811/head:pull/1811 PR: https://git.openjdk.org/valhalla/pull/1811
