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

[Peter Levart]

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

>
> /Claes
>
>
> Peter Levart <peter.levart at gmail.com> skrev: (8 november 2015 18:28:03 
> CET)
>
>
>
>     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
>>
>
>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.