RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches

Claes Redestad claes.redestad at oracle.com
Mon Nov 9 00:47:28 UTC 2015

On 2015-11-08 20:40, Peter Levart wrote:
> On 11/08/2015 06:46 PM, Claes Redestad wrote:
>> It's worth considering, but j.l.reflect is already initialized by 
>> this point in jake and I saw no real difference in heap dumps or 
>> class loading order between this and an experiment where the ZERO 
>> constants were simply made public. Adding methods to JavaLangAccess 
>> has its own overheads to consider as well.
> There's probably really a very minimal impact to using reflection. You 
> say that some code already performs reflection on Byte, Short, 
> Character, Integer, Long, Float, Double at boot time? The footprint 
> overhead is a SoftReference<ReflectionData> + an array of Field[] with 
> Field object(s) in j.l.Class instances for those classes. j.l.Integer 
> for example, contains 11 fields (static included).
> Regards, Peter

You're mostly right: the ReflectionData is all hiding behind that 
soft-referenced ReflectionData, so in the HeapDumpAfterFullGC dumps I've 
been looking at those instances must've been cleared. However, the heap 
itself had grown an extra 25Kb in the reflection case, so I'll go with 
SharedSecrets approach for now.

On 2015-11-08 21:35, Aleksey Shipilev wrote:
> a) Pulling ZERO via Reflection: is this actually the best we can do? I
> have no answer, but this does look moderately ugly. I agree that
> exposing these constants as public is not good, as it precludes further
> improvements in autoboxing elimination.

Sure, see above.

> b) Given that startup code is probably running in interpreter, doing the
> compiler's job in loop splitting to avoid branch for zero seems a good
> tactics, so:
>   * Byte loop should use the same idiom as Char:
>       cache[0] = ZERO;
>       for (int i = 1; ...) {
>           ...
>       }

No, ByteCache goes from -128 to 127.

>   * Integer/Long/Short loops may look better if we split the loop into
> "negative", ZERO, and "positive" parts?

Sure, this might get a bit ugly, but here's my take:


Thanks for looking at this!


More information about the core-libs-dev mailing list