RFR: JDK-8199781: Don't use naked == for comparing oops (original) (raw)

Roman Kennke rkennke at redhat.com
Mon Mar 26 13:16:56 UTC 2018

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>

More information about the hotspot-gc-dev mailing list