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

[Peter Levart]

On 11/08/2015 06:08 PM, Peter Levart wrote:
>
>
> On 11/08/2015 02:43 PM, Claes Redestad wrote:
>> Hi,
>>
>> indy eagerly creates and initializes all integral type caches 
>> (Byte$ByteCache, Short$ShortCache) which has a small, measurable
>> impact to jake startup and footprint. Exposing ZERO constants from 
>> Byte, Character, etc which are guaranteed to be identical to what's
>> returned from each respective valueOf(0) enables j.l.i. to initialize 
>> without eagerly creating these caches:
>>
>> webrev: http://cr.openjdk.java.net/~redestad/8141678/webrev.01
>> bug: https://bugs.openjdk.java.net/browse/JDK-8141678
>>
>> Making these constants public would allow us to not fetch them via 
>> reflection for a tiny, incremental startup improvement, but I don't
>> think the constants carry their own weight to motivate them becoming 
>> part of public API.
>
> Do they have to be the same interned instances as returned from 
> XXX.valueOf() methods? If not, then constructing new instances could 
> be cheaper than using reflection which also triggers a bunch cache 
> initialization (think cached Field object(s) on j.l.Class objects for 
> wrapper classes).

I guess they have to be identical instances as returned by XXX.valueOf() 
methods. An alternative to using reflection would be making constants 
package-private and using SharedSecrets. JavaLangAccess is probably 
already set when sun.invoke.util.Wrapper is needed by jake or not?

>
> Regards, Peter
>
>>
>> Testing: verified startup/footprint improvement, various jtreg tests
>>
>> /Claes
>