RFR 8047737 Move array component mirror to instance of java/lang/Class
Peter Levart
peter.levart at gmail.com
Wed Jul 2 12:41:22 UTC 2014
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.
>
>>
>> Regards, Peter
>>
>
More information about the core-libs-dev
mailing list