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

[Vladimir Ivanov]

Looks much better now. Reviewed.

Best regards,
Vladimir Ivanov

On 11/9/15 4:36 PM, Claes Redestad wrote:
> 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
>