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

[Roman Kennke]

So where are we with this change?

There's not many places where I can think of possible performance
problems. Probably the most crucial ones are the oop/narrowOop/object
iterators that are used by GC. OopClosure and subclasses get pointers to
oop/narrowOop.. it shouldn't make a difference. Then there's
ObjectClosure which receives an oop. Does it make a difference there?
Maybe write a little benchmark that fills the heap with many small
objects, and runs an empty ObjectClosure over it? If it doesn't show up
there, I'm almost sure it's not going to show up anywhere else...

Roman

> Hi Coleen,
> 
> Thanks for the review.
> 
> On 2018-02-26 20:55, 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?
> 
> I assume so too. Or at least that the performance does not regress.
> Maybe I run some benchmarks to be sure since the question has been asked.
> 
> Thanks,
> /Erik
> 
>> 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
>>
>