RFR: 8141678: sun.invoke.util.Wrapper eagerly initializes all integral type caches
Vladimir Ivanov
vladimir.x.ivanov at oracle.com
Tue Nov 10 18:53:31 UTC 2015
Thanks for the correction, John!
I completely overlooked MH type conversions and a note in
MethodHandle.constant about widening primitive conversion when primitive
constant if requested.
Claes, the test looks good! Probably it is worth an RFE for additional
test development in that area.
Regarding the fix, can we avoid touching primitive boxes and lazily
cache the values on Wrapper side? "static final @Stable Object[] zeros"
+ Wrapper.zero() indexing that array by Wrapper.ordinal().
Best regards,
Vladimir Ivanov
On 11/10/15 12:18 AM, John Rose wrote:
> 1. If the Wrapper.zero "leaks" as a reference into any of the public 292 API, that would be a bug, since the API specifies that the conversion from a zero to a box-reference is the same as mandated by the JLS for boxing conversion. (This is like Integer.valueOf(x), not new Integer(x).)
>
> 2. Since Wrapper is private, perhaps it is used in such a way that all the references are hidden appropriately. This is hard to prove and maintain, since some of the conversion functions used by asType are associated with Wrapper, and may (on occasion) call Wrapper.zero to provide a user-visible converted reference value. That would be a bug.
>
> 3. If there are no such bugs, at least the access function Wrapper.zero should prominently and carefully document the fact that it is returning an uninterned zero value, which may be incompatible with the intended use (if the use is to emulate JLS boxing conversation, like asType or explicitCastArguments.)
>
> For example:
> * <li>If the return type <em>T0</em> is void and <em>T1</em> a primitive,
> * a zero value is introduced.
>
> Test case:
> MH h1 = MHs.constant(42);
> MH h2 = h1.asType(methodType(void.class)); // drop 42
> MH h3 = h2.asType(methodType(int.class)); // add 0
> MH h4 = h4.asType(methodType(Object.class)); // box
> Object x = h4.invokeExact();
> assert(x.equals(0));
> assert(x == Integer.valueOf(0));
>
> — John
>
> On Nov 9, 2015, at 4:13 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> 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