RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot

[David Holmes]

On 28/10/2017 6:20 AM, coleen.phillimore at oracle.com wrote:
> 
> Incremental webrev:
> 
> http://cr.openjdk.java.net/~coleenp/8189610.incr.01/webrev/index.html

That all looks fine - thanks.

If I get a chance I'll look deeper into why the VS compiler needs 0 to 
be cast to jint (aka long) to avoid ambiguity with it being a NULL 
pointer. I could understand if it always needed the cast, but not only 
needing it for long, but not int.

Thanks,
David

> thanks,
> Coleen
> 
> On 10/27/17 11:13 AM, coleen.phillimore at oracle.com wrote:
>>
>>
>> On 10/27/17 9:37 AM, David Holmes wrote:
>>>>> src/hotspot/share/c1/c1_LinearScan.cpp
>>>>>
>>>>>  ConstantIntValue((jint)0);
>>>>>
>>>>> why is this cast needed? what causes the ambiguity? (If this was a 
>>>>> template I'd understand ;-) ). Also didn't you change that 
>>>>> constructor to take an int anyway - not that I think it should - 
>>>>> see below.
>>>>
>>>> Yes, it caused an ambiguity.  0 matches 'int' but it doesn't match 
>>>> 'long' better than any pointer type.  So this cast is needed.
>>>
>>> But you changed the constructor to take an int!
>>>
>>>  class ConstantIntValue: public ScopeValue {
>>>   private:
>>> -  jint _value;
>>> +  int _value;
>>>   public:
>>> -  ConstantIntValue(jint value)         { _value = value; }
>>> +  ConstantIntValue(int value)          { _value = value; }
>>>
>> I changed this back to not take an int and changed c1_LinearScan.cpp 
>> to have the (jint)0 cast and output.cp needed (jint)0 casts.  0L 
>> doesn't work for platforms where jint is an 'int' rather than a long 
>> because it's ambiguous with the functions that take a pointer type.
>> Probably better to keep the type of ConstantIntValue consistent with j 
>> types.
>>
>> Thanks,
>> Coleen
>