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

John Rose john.r.rose at oracle.com
Mon Mar 26 19:11:49 UTC 2018

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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180326/92ad5f57/attachment.htm>

More information about the hotspot-gc-dev mailing list