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

[John Rose]

On Mar 26, 2018, at 6:16 AM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> 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.

Thank you; I think this is the right step even if there is evidence
that an out-of-line oopDesc::equals might be harmless, in today's
code base with today's benchmarks.

HotSpot is built (today) using the C++ performance model where
inlining is the safe way to boil down abstract operations to concrete
one.  In the case of operator==, the concrete operation is a single
instruction (or sometimes no instructions at all, with a clever optimizer).

We know it's often harmless to replace such an optimizable operation
with a much heavier one (a function call that won't be inlined, in this
case).  But, in the case of *very simple* concrete operations like op==,
there is always a risk of a future well-meant code change causing a
sudden and surprising performance regression, as well as a rarely
taken code path suddenly failing to scale in the field.

So our customary treatment of very simple concrete operations
is to abstract them however we like, but express their abstractions
in terms of inlines, wherever there might be risk of performance
surprises.

This is clearly one of those cases.  Let's code against surprises
(both present and future) by abstracting simpler operations with
inlines.

— John