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

[Andrew Haley]

On Tue, 29 Jun 2021 11:35:52 GMT, 王超 <github.com+25214855+casparcwang at openjdk.org> wrote:

>> Lots of c1 and c2 jit methods do not contain any oop, so the nmethod entry barrier can be skipped.
>> 
>> 1, c1 jit code will patch oops or Klass into the nmethod, so the entry barrier cannot directly be eliminated, current implementation uses a jump instruction to replace the jcc instruction. If the jit code is patched to contain oops, the entry barrier is patched back to the jcc instruction.
>> 
>> 2, only the jit code of core library methods do not contain any oops.
>> 
>> 3, currently only support zgc
>
> 王超 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix assert error

On 6/29/21 2:16 PM, Erik Österlund wrote:
>> On 6/29/21 8:03 AM, Erik Österlund wrote:
>>> 1) When this was introduced, we did not see the overhead of nmethod entry barriers in performance profiles. Did you see any improvement with the patch?
>>
>> This is a LoadLoad fence at the start of every method followed by a load
>> with a dependent branch. If there wasn't a significant hit in the profiles
>> I wouldn't believe the profiles. Even adding code that doesn't appear to slow
>> things down uses additional speculation resources.
> 
> My main concern is that I am not convinced that eliding nmethod entry barriers is sound. It really isn't all about protecting oops found in the machine code as I explained previously. There is a lot more to it. Therefore I would like to at least have some convincing number showing that such an optimization effort is worthwhile.
> 
> If you are looking at ways of getting rid of the loadload, I have a scheme that can elide it if you are interested. I discussed it with Stuart when he was prototyping how to build these barriers, but I think he concluded we didn't need such optimizations in the end. It came with some more complexity. That's why I am curious if you have numbers suggesting the opposite. Because if so, I have a better idea to target the loadload in particular, witout violating our invariants and still being correct.

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.

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

-------------

PR: https://git.openjdk.java.net/jdk/pull/4610