RFR: 8209120: Archive the Integer.IntegerCache (original) (raw)

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 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

More information about the core-libs-dev mailing list