RFR: JDK-8199781: Don't use naked == for comparing oops

[Roman Kennke]

Am 26.03.2018 um 11:38 schrieb Andrew Haley:
> On 03/21/2018 04:58 PM, Roman Kennke wrote:
> 
>> I believe that inline is over-used in OpenJDK too. It might be
>> better to start out with regular methods and *if* they show up in
>> profiles, consider to inline them. Would that be acceptable?
> 
> I don't believe so.  Efficient systems are made from thousands of tiny
> incremental improvements, each one of which is too small to be
> measured on its own.
> 

I don't generally agree. Efficient systems are made of efficient
algorithms. Tiny little improvements (aka microoptimizations) like
inlining all sorts of stuff just because.. can also backfire. I have
checked the uses of the new equals() function, and there are not many
that look like they would be performance sensitive.

However, in order to not cause regressions in any code I might have
overlooked, I did change the new stuff to inlining, and hunted down the
places where it breaks compilation.

Differential:
http://cr.openjdk.java.net/~rkennke/JDK-8199781/webrev.02.diff/
Full:
http://cr.openjdk.java.net/~rkennke/JDK-8199781/webrev.02/

One thing I was not sure of if it's worth refactoring into .inline.hpp
pattern is the change around stackValue.hpp.

There is still one slightly problematic use of oopDesc::equals() in
growableArray.hpp, but I don't see how to fix that (i.e. refactor into
growableArray.inline.hpp or such) without causing a mess (this stuff is
used throughout C2 headers, e.g. compile.hpp). This means that code that
includes growableArray.hpp also currently also needs to include
oop.inline.hpp.

Is the patch acceptable now?

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180326/aba8f7d3/signature.asc>