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

[Kim Barrett]

> On Mar 14, 2018, at 8:46 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
> 
> Hi Roman,
> 
> Sorry for the delay. Here is a status update:
> 
> 1. I looked at the generated machine code from a bunch of different compilers and found that it was horrible.
> 2. Found that the biggest reason it was horrible was due to unfortunate uses of volatile in oop. Was easy enough to solve:
> 
> Full webrev: http://cr.openjdk.java.net/~eosterlund/8198561/webrev.02/
> Incremental: http://cr.openjdk.java.net/~eosterlund/8198561/webrev.01_02/
> 
> 3. Found that even after solving the accidental volatile problems, oops sent as value as arguments to functions were sent on the stack (not register), because oop is not a POD, and this is seemingly a strict ABI requirement of C++. Optimizing it would be an ABI violation and is therefore not done.
> 4. Found that oop is inherently not going to be a POD unless we rewrite a *lot* of code in hotspot due to having e.g. volatile copy constructor (which can not be auto generated) and a popular user defined oopDesc* constructor.
> 5. Got sad that C++ really has to send wrapper objects as simple as oop through the stack on callsites and dropped this as I did not know how I felt about it any longer.
> 
> You can pick this up where I left if you want to and check if the performance impact due to the suboptimal machine code is something we should be scared of or not. If there is reason to be scared, I wonder if LTO mechanisms can solve part of this and a whole bunch of unnecessary use of .inline.hpp files at the same time.

I wonder if the situation changes at all with C++11, where these classes could probably be
made “standard-layout” (if they aren't already).