RFR: 8269476: Skip nmethod entry barrier if there is no oops in the jit code [v4]

[John Rose]

On Jun 30, 2021, at 9:52 AM, Andrew Haley <aph at openjdk.java.net<mailto:aph at openjdk.java.net>> wrote:

No, I don't have numbers, and it would be a moderately serious effort to get them.
I could do it, but it seems like a ridiculous effort to eliminate something that
obviously should be eliminated.

I’ll pile on here, because there seem to be a number
of interesting issues in play: nmethod dynamics,
special-purpose vs general-purpose mechanisms,
speculatively applied optimizations, and instruction
patching.

There are obvious micro-benchmarks where the cost
of nmethod entry would be detectable.  But nmethods
tend to be large and loopy and calls to them are typically
infrequent and expensive.  (Expenses include spilling
registers, redoing checks on inputs, and lots more.)

So I do think the burden of proof is on any proposer
of nmethod linkage changes to show objective
evidence of performance effects, either neutral
in the case of cleanups or enhancements, or
improvements in the case of purported
“optimizations” that rely on tricky code.

Meanwhile, this change “optimizes” a general
mechanism under the theory that it’s only for
one purpose, so we’d tax all additional uses of
Erik’s “swiss army knife” in the future.  As some
may know, I am fond of such swiss army knives.
HotSpot ought to have a goodly collection of
them.  (See current efforts to upgrade the
hash tables, for example.)

Also, without fully understanding the specific
issue, I’m nervous about the comments that the
conditions for applying the “optimization” are
hard to state and hard to check.  We all know that
a “fingers crossed” approach to gating optimizations
leads to crashes in the future and headaches for
everybody.  I’m not against optimizations “just
because it’s obviously beneficial”, but they also
have to be obviously reliable and maintainable,
or, if not, we have to prove they are worth the
short- and long-term costs.

The specific thing that scares me about this change
is that the entry barrier has a complex state diagram.
The barrier is elided but can be inserted again later.
Among all optimization tactics we use, instruction
patching has (probably) the highest cost in terms
of risk of race conditions and unpredictable behavior
on present and future platforms.

Also, this particular change requires platform
specific changes.  Those are expensive, although
the cost in this case may be lower because they
are optional.  (Actually, it’s not lower, just deferred,
because eventually other platforms would adopt
the changes, in the name of regularity.)

To me all that sounds costly, except for an unproven
performance gain on some platforms with some
configurations.

So I’m glad this PR is withdrawn.  If we find out later
that nmethod call overhead is a problem, let’s take
a broader approach to it.  We can consider this PR
to be a proof of concept, that there are some ways to
reduce nmethod call overhead.

I do appreciate the hard work that Caspar put into
designing and coding this PR.  And yet I *also* appreciate
that the review process prevented this proof of concept
from being committed in its present state.

— John