RFR: 8209120: Archive the Integer.IntegerCache

[Peter Levart]

On 08/09/2018 05:32 PM, Peter Levart wrote:
> Hi Claes,
>
> When is this archived cache created? Is it possible to create archived 
> cache with java.lang.Integer.IntegerCache.high system property set to 
> > 127 ? Wouldn't then at runtime, when cache is initialized from such 
> oversized archive and no java.lang.Integer.IntegerCache.high system 
> property is specified, the resulting cache array be to big?
>
> Perhaps you could allocate a copy of the prefix of the de-archived 
> array in that case to release the unused Integer instances.

There's danger when you overwrite a non-null @Stable field with another 
value that this new value will not be seen. Or is <clinit> code an 
exception where @Stable is not honored yet...

To mitigate this possibility, you could have two fields:

static Integer cache[];
static final Integer finalCache[];

The 'cache' field is archived and de-archived. The final result is set 
to 'cache' by overwriting and to 'finalCache'. The later is then also 
used in Integer.valueOf().

Peter

>
> Regards, Peter
>
> On 08/09/2018 01:33 PM, Claes Redestad wrote:
>> Hi,
>>
>> using the new ability to archive immutable heap graphs into the CDS 
>> archive, even archiving small things like the Integer.IntegerCache 
>> can be profitable.
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8209120/open.00/
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209120
>>
>> For a default cache (256 elements), this change saves us ~1 million 
>> instructions. Applications that use -XX:AutoBoxCacheMax can profit 
>> further (and we can use this to stress test the archiving feature..)
>>
>> The patch is built on top of and tested with Jiangli's patch for 
>> https://bugs.openjdk.java.net/browse/JDK-8207263 and I don't intent 
>> to push this before that is in.
>>
>> Thanks!
>>
>> /Claes
>>
>