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

[coleen.phillimore at oracle.com]

On 10/28/17 3:58 AM, David Holmes wrote:
> 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,  Kim can probably tell you where in the spec this is.

Coleen

>
> 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
>>