RFR: 8209120: Archive the Integer.IntegerCache

Peter Levart peter.levart at gmail.com
Thu Aug 9 15:41:56 UTC 2018

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().


> 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

More information about the hotspot-runtime-dev mailing list