RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches
Peter Levart
peter.levart at gmail.com
Sun Nov 8 17:28:03 UTC 2015
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
>
More information about the core-libs-dev
mailing list