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 11:00 AM, Andrew Haley wrote:

> 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.

I have numbers.

Running javac (@java.base) on AArch64 we execute on average 657152838
nmethod barriers. That number varies by as much as 2.5%, to be
expected given that compiler threads are racing with Java threads.

perf stats are typcally:

      77232.039076      task-clock:u (msec)       #    3.284 CPUs utilized
            933972      page-faults:u             #    0.012 M/sec
      167237276242      cycles:u                  #    2.165 GHz
      239468489262      instructions:u            #    1.43  insn per cycle
        1762368611      branch-misses:u

      23.520042515 seconds time elapsed

An nmethod barrier is 5 instructions, so the proportion of instructions
executed by nmethod barriers is

   (657152838.0*5)/239468489262 = 1.38%

That's quite a lot. I would have expected it to be noticeable. It
might well be that the barrier instructions commonly are (fully or
partially) speculated in parallel on a big out-of-order machine so
don't show up on a wall clock, but they will show up in perf
stats. Also, that 1% is about the level of run-to-run variance even on
a quiet server, so it'd take many runs averaged out to see it. But the
effect is real; unless I have messed up my measurements or my
thinking, which happens.

-- 
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