On Thu, 31 Oct 2024 07:32:01 GMT, Aleksey Shipilev <[email protected]> wrote:
>> The runtime cache would only store the additional boxed Integers not in the
>> archived cache, without affecting the archived boxed Integers. Something
>> like the following would work (I didn't test all corner cases):
>>
>>
>> static final int archivedSize;
>> ...
>> archivedSize = archivedCache == null ? 0 : archivedCache.length;
>> if (archivedCache == null || size > archivedCache.length) {
>> int runtimeCacheSize = size - archivedSize;
>> Integer[] c = new Integer[runtimeCacheSize];
>> int j = low + archivedSize;
>> for(int i = 0; i < runtimeCacheSize; i++) {
>> c[i] = new Integer(j++);
>> }
>>
>> cache = c;
>> if (archivedCache == null) {
>> archivedCache = c;
>> }
>> } else {
>> cache = null;
>> }
>>
>>
>> `Integer.valueOf()` would retrieve the cached boxed Integer either from the
>> archived cache or the runtime created cache, if the value is within the
>> runtime [low, high].
>>
>>
>> public static Integer valueOf(int i) {
>> if (i >= IntegerCache.low && i <= IntegerCache.high) {
>> int index = i + (-IntegerCache.low);
>> if (IntegerCache.archivedSize != 0 && IntegerCache.archivedSize
>> >= index) {
>> return IntegerCache.archivedCache[index];
>> } else {
>> return IntegerCache.cache[index - IntegerCache.archivedSize];
>> }
>> }
>> return new Integer(i);
>> }
>
> Ah, I see. I don't think we want to do this, though. I vaguely remember
> `Integer.valueOf` code shape being important for things like C2 optimizations
> around EA and autoboxing elimination. The beauty of staying within a single
> array is avoiding a whole class of these issues.
I think it's mostly ok if we don't take the archivedCache+runtimeCache
approach. The overhead is not too large in common cases, as likely the
archivedCache would have the default size if runtime changes to use a different
`high` value.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21737#discussion_r1824689846
