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

Coleen Phillimore coleen.phillimore at oracle.com
Wed Jul 2 17:05:00 UTC 2014


Hi Mandy,

The componentType field is the last one that I'm planning on moving out 
for now, so I'd like to keep the code as is.  If more are added because 
of more performance opportunities, I think we can revisit this.

I agree with Doug that we don't want any more special code like this in 
the JVM to disable these optimizations if they are ever implemented.

Thank you for reviewing the code.
Coleen

On 7/2/14, 2: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
>




More information about the core-libs-dev mailing list