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

[Andrew Haley]

On 6/30/21 9:02 PM, John Rose wrote:
> 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.)

True enough: method calls are expensive, particularly because we don't
have any callee-preserved registers. The notion that "calls are
expensive" has IMVHO caused us to ignore some things that could make
them cheaper, such as frameless leaf methods. That is to say: to some
extent, the belief in an inevitable future can cause that future to
happen. If we hadn't had such expensive calls maybe we wouldn't have
needed to make so much effort to avoid them. And maybe we'd have had
to do less inlining, etc., and our caches would work better. Or maybe
not.  :-)

(Please forgive the somewhat pedagogical tone of the following: it
is the only way I know how to explain my thoughts.)

An efficient system includes thousands of tiny optimizations, each one
too small to be measured on its own, at least without heroic efforts.
This is perhaps more obvious in, e.g. automobile engines than it is in
the systems we create, but I think it's the same thing.

But lose them, and, one by one, the system slowly gets worse. Even if,
in isolation, adding some code makes no difference in speed, you have
made something worse.  The most likely reason nothing slowed down is
that a superscalar CPU managed to run your extra instructions in
parallel. But it does cost, even if the result was delivered to the
user in the same time, in terms of power consumption. Also, it reduces
the availability of speculation resources which might be used for
useful work in a slightly different run of the same program.

I am going to take a little to to quantify, hopefully in percentage
terms, the cost of nmethod barriers, as much for my own education as
anything else. I'll get back to y'all.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley