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
