On Tue, 31 Mar 2026 14:34:11 GMT, Chen Liang <[email protected]> wrote:
>> There are some inconsistencies. For instance, Integer sees its `cache` as >> non-final, so I think a `@Stable` makes sense there given that the setup is >> performed outside of the static initializer. It's not immediately clear to >> me why this decision was made, but this is also how it is in mainline. >> >> Moving forwards, I propose: >> * Ensure all `cache` variables are consistent with mainline and either >> `static final` or `@Stable static`. >> * If in preview, `static final` caches with `null` and `@Stable static` >> caches with an empty array. >> * Remove `isEnabled`. >> * Revert changes in `valueOf`, i.e., call `PreviewFeatures`. >> >> Thoughts? > > On mainline Integer's cache is not final because the archived data may be > invalid and need to be thrown away if a system property is changed. (This has > always been the biggest headache with AOT) > > @xmas92 I think only `IntegerCache.cache` is non-final `@Stable`. Others seem > to be final `@Stable`. A final `@Stable` is meaningful for arrays because a > read of such an array element is considered a compiler constant if it is > non-zero/null. > If in preview, `static final` caches with `null` and `@Stable static` caches > with an empty array. If we do not touch the cache array at all in preview, we can leave that array null because it won't be touched by code and thus won't be dealt by JIT. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2249#discussion_r3016344224
