On Fri, 15 Oct 2021 15:09:23 GMT, Peter Levart <plev...@openjdk.org> wrote:
>> It's not driven by performance data. It's part of Peter's contribution. >> I also prefer it without the packing. I propose to keep the parameter >> count as a separate field and examine it when there is footprint issue. > > The reason for this packing is (was) ORing the value with a non-zero value so > that field never held zero value. When for example an individual value (say > paramCount) is used in a separate @Stable field, its value set may include > the default value (zero) which is then not optimized by JIT as a constant. > This is from @Stable docs: > > * By extension, any variable (either array or field) which has annotated > * as stable is called a stable variable, and its non-null or non-zero > * value is called a stable value. > > ...and: > > * The HotSpot VM relies on this annotation to promote a non-null (resp., > * non-zero) component value to a constant, thereby enabling superior > * optimizations of code depending on such a value (such as constant folding). > * More specifically, the HotSpot VM will process non-null stable fields > (final > * or otherwise) in a similar manner to static final fields with respect to > * promoting the field's value to a constant. Thus, placing aside the > * differences for null/non-null values and arrays, a final stable field is > * treated as if it is really final from both the Java language and the > HotSpot > > So now that some of these fields are final and not annotated with @Stable any > more but are treated as "trusted final" fields, the question is whether JIT > is treating the default (zero, null) values differently or not. If they are > treated as static final fields where default value makes no difference, then > it's ok to split this multi-valued field into individual fields. The compiler team confirms that the zero value only matters for stable fields. For static/trusted non-static final fields, zero value is treated as a constant. ------------- PR: https://git.openjdk.java.net/jdk/pull/5027
