RFR 8047737 Move array component mirror to instance of java/lang/Class

Coleen Phillimore coleen.phillimore at oracle.com
Wed Jul 2 13:16:29 UTC 2014


On 7/2/14, 8:41 AM, Peter Levart wrote:
> On 07/02/2014 02:38 PM, Peter Levart wrote:
>> On 07/02/2014 02:22 PM, Peter Levart wrote:
>>> On 07/02/2014 08:26 AM, Mandy Chung wrote:
>>>>
>>>> On 6/30/2014 9:51 PM, Christian Thalinger wrote:
>>>>> On Jun 30, 2014, at 5:50 PM, Coleen Phillimore 
>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>
>>>>>
>>>>> On 6/30/14, 3:50 PM, Christian Thalinger wrote:
>>>>>>>       private Class(ClassLoader loader) {
>>>>>>>           // Initialize final field for classLoader. The 
>>>>>>> initialization value of non-null
>>>>>>>           // prevents future JIT optimizations from assuming 
>>>>>>> this final field is null.
>>>>>>>           classLoader = loader;
>>>>>>> +        componentType = null;
>>>>>>>       }
>>>>>>>
>>>>>>> Are we worried about the same optimization?
>>>>>> Hi,  I've decided to make them consistent and add another 
>>>>>> parameter to the Class constructor.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~coleenp/8047737_jdk_2/
>>>>
>>>> The jdk change looks okay while I am beginning to think whether we 
>>>> really want to keep expanding this constructor to deal with this 
>>>> future JIT optimization (you will be moving more fields out from 
>>>> the VM to java.lang.Class).
>>>>
>>>> There are places in JDK initializing the final fields to null while 
>>>> the final field value is overridden via native/VM - e.g. System.in, 
>>>> System.out, etc.  I would prefer reverting the classLoader 
>>>> constructor change to expanding the constructor for any new field 
>>>> being added.  Handle it (and other places in JDK) when such JIT 
>>>> optimization comes.
>>>>
>>>> Mandy
>>>>
>>>
>>> What about:
>>>
>>>
>>>     private Class() {
>>>         classLoader = none();
>>>         componentType = none();
>>>         ...
>>>     }
>>>
>>>     private <T> T none() { throw new Error(); }
>>>
>>>
>>> I think this should be resistant to future optimizations.
>>
>> And you could even remove the special-casing in 
>> AccessibleObject.setAccessible0() then.
>>
>> Regards, Peter
>
> I take it back. Such java.lang.Class instance would still be 
> constructed and GC will see it.

The setAccessible0 check is still needed because we do other things to 
the mirror inside the jvm.
Coleen

>
>>
>>>
>>> Regards, Peter
>>>
>>
>




More information about the core-libs-dev mailing list