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

[Andrew Haley]

On 03/29/2018 10:39 AM, Andrew Dinn wrote:
> Wrong Andrew here, I am afraid. However, I am butting in just to place
> on record that this /one file/ is quite probably the most unmaintainable
> piece of code I have ever been witness to in 35 years of professional
> software development (and, yes, that includes the Interlisp-D machine's
> reference counting GC which had invisible microcode support (Pope's
> 'butterfly on a wheel' [1] springs to mind :-).
> 
> Although I am very glad to hear (and even more glad to take it on
> assurance ;-) that the compiler understands enough to inline it all
> away, my real concern is whether anyone else will still understand it in
> 6 months or 1 year if (when?) a bug manifests. Especially if bug is
> caused by misguided and/or unexpected usage in the JIT or (more likely)
> JVM runtime code.

With regard to whether the compiler understands enough to inline it
all, it probably will but there's no guarantee.  When Stepanov was
writing STL he coined the phrase "Abstraction Penalty" which claims to
be the factor by which you will be punished by your compiler if you
attempt to use C++ data abstraction features.  Back then there were
some severe penalties, so C++ compiler writers did a lot of work to
fix them.  These days, because of heavy use of STL and suchlike, the
Abstraction Penalty is usually 1, i.e. there is no penalty.

I agree, though, that accessBackend.new.hpp is a frightening piece of
code written in an idiom that's very different from the rest of
HotSpot.  I doubt that its usefulness exceeds its maintenance burden.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671