RFR 8047737 Move array component mirror to instance of java/lang/Class
Mandy Chung
mandy.chung at oracle.com
Wed Jul 2 17:21:33 UTC 2014
I wasn't aware of the VM special case of System.{in,out,err} fields that
Doug pointed out (thanks. I should have checked). That's okay with me.
Mandy
On 7/2/2014 10:05 AM, Coleen Phillimore wrote:
>
> 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