Hi Peter,
On 2018-08-09 17:32, Peter Levart wrote:
Hi Claes,
When is this archived cache created?
The cache you build when dumping the archive is serialized, so java
-Xshare:dump -XX:AutoBoxCacheMax=20000 would create an array with 20k
elements in the archive...
Is it possible to create archived cache with
java.lang.Integer.IntegerCache.high system property set to > 127 ?
Yes. I'm going to add a test that all variants work though, as Alan
suggested.
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.
The array would be too big, true, but it's backed by the read-only data
in the archive directly, so while the Objects might appear in a heap
dump, creating them happens at no extra cost and keeping them shouldn't
actually cause any real (rss) memory footprint (GC shouldn't be scanning
the memory, either).
As accesses to the array is guarded by checking IntegerCache.high (and
not cache.length) we won't return cached Integers outside of the
requested range, either.
So unless I'm mistaken, defensively allocating a copy shouldn't be
necessary.
/Claes
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
