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

[Claes Redestad]

Vladimir,

thanks for asserting this. The j.l.invoke code is still rather foreign 
to me, so I took extreme precautions to not change any semantics.

Simplified thusly:

http://cr.openjdk.java.net/~redestad/8141678/webrev.03/

Effects remain largely the same.

Thanks!

/Claes

On 2015-11-09 13:13, Vladimir Ivanov wrote:
> Claes,
>
> I don't think Wrapper.zero identity matters (e.g. see 
> MethodHandles.constant [1] or InvokerBytecodeGenerator.emitConst).
>
> So, you can considerably simplify your code by allocating fresh 
> wrapper instances.
>
> Best regards,
> Vladimir Ivanov
>
> [1] public static
>     MethodHandle constant(Class<?> type, Object value) {
> ...
>             if (w.zero().equals(value))
>                 return zero(w, type);
>
>
> On 11/8/15 4: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.
>>
>> Testing: verified startup/footprint improvement, various jtreg tests
>>
>> /Claes