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.
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.
- links to
-
Review(lworld)
openjdk/valhalla/1811