RFR (S): 8198561: Make oop and narrowOop always have their own class type

[Erik Österlund]

Hi Roman,

Thank you for the review.
The solaris ifdef stuff in oopsHierarchy.hpp (if that was what you were 
referring to) is there because the studio compiler incorrectly thinks 
having both a const implicit conversion operator and a const volatile 
implicit conversion operator is ambiguous. The same problem occurred in 
oopDesc to void* conversion.

The good news is that my latest revision manages to get rid of this by 
adding a narrowOop(const volatile narrowOop& o) constructor instead.

Thanks,
/Erik

On 2018-02-26 21:11, Roman Kennke wrote:
> This is a very welcome change!
> Changeset looks good to me (except I've no idea what the sparc part
> does). Same question as Colleen though.
>
> Thanks,
> Roman
>
> On Mon, Feb 26, 2018 at 8:55 PM,  <coleen.phillimore at oracle.com> wrote:
>> Hi Erik,
>>
>> This looks great.   I assume that the generated code (for these classes vs.
>> oopDesc* and juint) comes out the same?
>>
>> thanks,
>> Coleen
>>
>>
>> On 2/26/18 8:32 AM, Erik Österlund wrote:
>>> Hi,
>>>
>>> Making oop sometimes map to class types and sometimes to primitives comes
>>> with some unfortunate problems. Advantages of making them always have their
>>> own type include:
>>>
>>> 1) Not getting compilation errors in configuration X but not Y
>>> 2) Making it easier to adopt existing code to use Shenandoah equals
>>> barriers
>>> 3) Recognize oops and narrowOops safely in template
>>>
>>> Therefore, I would like to make both oop and narrowOop always map to a
>>> class type consistently.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8198561/webrev.00/
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8198561
>>>
>>> Thanks,
>>> /Erik
>>