[External] : The cost of nmethod entry barriers [was: RFR: 8269476: Skip nmethod entry barrier if there is no oops in the jit code [v4]]

[Andrew Haley]

On 7/1/21 9:56 PM, John Rose wrote:

> So for javac (which BTW has a lot of polymorphism in it)

Ha! Good point, I hadn't thought of that. javac is my pet program for
testing compiler tweaks because it's complex, does a lot of
(re)compiling, requires no setting up or external dependencies, and
it's there.

> the dynamic proportion of retired nmethod entry
> instructions is 1.38%.  Unless those instructions are
> unusually slow ones, that percentage is an upper limit
> to their wall clock contribution.

Probably, but one of them is a LoadLoad fence, whose cost is horribly
difficult to quantize because that cost depends entirely on what is
going on around the instruction. That is to say, fences can restrict
speculation and speculation is what makes our fastest processors
fast. However, I understand that some processors speculate past memory
fence instructions, so that may not be such a big issue.

> If we can get rid of 2 out of 5 of them, the estimate would be
> 0.83%, with a savings of 0.55% (upper bound).

Depending on the cost of that fence, yes.

But, for avoidance of doubt, I'm not arguing for 8269476. My goal here
is to provide some clarity about the costs of nmethod barriers, mostly
because I've seen them dismissed as insignificant. They're not. That
1.38% figure surprised me. I hadn't expected it to be as insignificant
as people made it out to be, but ... wow.

That doesn't mean that nmethod barriers are bad, of course.

> BTW, that 1.38% is a *lower* limit for nmethod overhead proper,
> because it doesn’t count the effects of lost inlining, which are
> surely at least as large.  The combined effects of lost inlining
> (whatever they are) are IMO the root reason why we keep piling on
> more and more inlining tactics, trying to make nmethods large and
> calls infrequent.

That's a good point too.

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