[PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers

Johannes Kuhn info at j-kuhn.de
Tue Nov 26 22:16:35 UTC 2019


Hi,

I saw Remi's reply after I sent my reply.
The questions I asked were just to confirm that my suspicion (int.class gets compiled into Integer.TYPE) were true - I am currently on mobile, so I couldn't test it myself.

In short, my mail doesn't provide any additional value, and if I had seen Remi's reply, I wouldn't have sent mine.

Best regards,
Johannes

On November 26, 2019 10:10:02 PM GMT+01:00, "Сергей Цыпанов" <sergei.tsypanov at yandex.ru> wrote:
>Hello,
>
>> I suspect that it will print null, because to my knowledge, int.class
>will be compiled to a getstatic Integer.TYPE, so your test basically
>tests if Integer.TYPE == Integer.TYPE.
>
>right, Remi pointed this out in his response.
>
>> Also, do the tier1 tests succeed with your patch?
>
>I'm going to do that as far as my work station is fixed, hope tomorrow.
>Apparently, something is going to go wrong :) Anyway, I'll notify about
>results when this is done.
>
>Regards,
>Sergey Tsypanov
>
>
>26.11.2019, 21:57, "Johannes Kuhn" <info at j-kuhn.de>:
>> On November 26, 2019 8:29:06 PM GMT+01:00, "Сергей Цыпанов"
><sergei.tsypanov at yandex.ru> wrote:
>>> Hello,
>>>
>>> while using java.lang.Integer.TYPE I've found out that currently
>>> wrapper classes for primitives initialize their own TYPE-fields by
>>> calling native method java.lang.Class.getPrimitiveClass().
>>>
>>> This can be simplified by changing existing declaration (here for
>>> java.lang.Integer)
>>>
>>> @SuppressWarnings("unchecked")
>>> public static final Class<Integer> TYPE = (Class<Integer>)
>>> Class.getPrimitiveClass("int");
>>>
>>> to
>>>
>>> public static final Class<Integer> TYPE = int.class;
>>>
>>> This is likely to improve start-up time as Class.getPrimitiveClass()
>is
>>> called 9 times (8 primitive type wrappers + java.lang.Void), after
>the
>>> change this method is not called at all and thus can be removed
>along
>>> with its backing C++ code on VM-side. The fields are initialized
>purely
>>> on Java side.
>>>
>>> I've verified correctness of the substitution with this test run on
>JDK
>>> 11
>>>
>>> @Test
>>> void name() {
>>>   assert void.class == Void.TYPE;
>>>   assert boolean.class == Boolean.TYPE;
>>>   assert byte.class == Byte.TYPE;
>>>   assert char.class == Character.TYPE;
>>>   assert short.class == Short.TYPE;
>>>   assert int.class == Integer.TYPE;
>>>   assert long.class == Long.TYPE;
>>>   assert float.class == Float.TYPE;
>>>   assert double.class == Double.TYPE;
>>> }
>>>
>>> The patch is attached.
>>>
>>> Regards,
>>> Sergey Tsypanov
>>
>> Hi,
>> a few questions:
>> What does System.out.println(int.class); with your patch print? "int"
>or "null"?
>>
>> I suspect that it will print null, because to my knowledge, int.class
>will be compiled to a getstatic Integer.TYPE, so your test basically
>tests if Integer.TYPE == Integer.TYPE.
>>
>> Also, do the tier1 tests succeed with your patch?
>>
>> With best regards,
>> Johannes


More information about the core-libs-dev mailing list