RFR (S): 8198561: Make oop and narrowOop always have their own class type
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Tue Feb 27 14:51:08 UTC 2018
On 2/27/18 9:50 AM, Erik Österlund wrote:
> Hi Coleen,
>
> As I said to Roman: the studio compiler finds it ambiguous to have
> both const and const volatile implicit conversion overloads - you
> gotta pick your favourite. Seemingly same issue as oopDesc* -> void*
> where solaris is forced to pick just one. But my latest revision
> http://cr.openjdk.java.net/~eosterlund/8198561/webrev.01/ managed to
> get rid of it by introducing a new constructor accepting const
> volatile narrowOop& instead.
That's great. I just wanted a comment but this is better now. This came
out very nicely.
Coleen
>
> Thanks,
> /Erik
>
> On 2018-02-26 21:27, coleen.phillimore at oracle.com wrote:
>> Yeah I forgot to ask for a comment why this is:
>>
>> http://cr.openjdk.java.net/~eosterlund/8198561/webrev.00/src/hotspot/share/oops/oopsHierarchy.hpp.udiff.html
>>
>>
>> +#ifndef SOLARIS
>> + operator PrimitiveType () const { return _value; }
>> +#endif
>> + operator PrimitiveType () const volatile { return _value; }
>>
>> Thanks,
>> Coleen
>>
>> On 2/26/18 3:11 PM, 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
>>>>
>>
>
More information about the hotspot-dev
mailing list