RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches
Claes Redestad
claes.redestad at oracle.com
Mon Nov 9 13:36:40 UTC 2015
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
More information about the core-libs-dev
mailing list