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

[Erik Österlund]

On Mon, 28 Jun 2021 11:21:53 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:
> 
>   Only implement in x86

I don't think we should do this at all.

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?
2) Any method that can be on-stack has at least an oop for the method holder, to prevent the method from being unloaded.
3) These barriers are like a swiss army knife. They do not only protect against oops in machine code. As mentioned they also protect against the class being unloaded, and racing between unloading and loading. In project loom they are also used for the nmethod lifecycle, and in generational ZGC they are used to patch the barrier code itself.
4) Having special nmethods that don't quack the same way makes the GC code unintuitive to work with and understand.

In summary, I don't think we should be eliding any nmethod entry barriers.

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

Changes requested by eosterlund (Reviewer).

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