RFR: 8290700: Optimize AArch64 nmethod entry barriers

[Erik Österlund]

On Wed, 20 Jul 2022 16:54:53 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

> The original nmethod entry barrier supported only concurrent patching of data and was used by ZGC to solve concurrent class unloading problems. Now it is starting to see more uses. Notably, loom uses nmethod entry barriers to figure out what nmethods have been seen on-stack, needed to remove nmethods safely. However, the concurrent data patching variation was too slow for loom (showed a few regressions), so I brought over a faster nmethod entry barrier that we use in the generational ZGC repo, which additionally handles concurrent patching of data and instructions, which is needed there. 
> However, I still see some small regressions. So for the uses in loom, the classic GCs don't really patch anything interesting concurrently. This leads to the following possible enhancements to improve the situation: 
> 
> 1. Make a dedicated nmethod entry barrier for GCs that don't patch data nor code concurrently, consisting of basically only a conditional branch. There is no need to penalize STW GCs with seat belts protecting against concurrent races that simply do not exist.
> 
> 2. Move the "guard" word and call into the VM trampoline, to an out-of-line stub towards the end of the nmethod, ensuring instruction caches are not polluted by non-hot instructions at the nmethod entry. Some machines also better optimize the branch-not-taken path of conditional branches.
> 
> With these optimizations, the small regressions did go away.

Note that this PR is dependent on https://github.com/openjdk/jdk/pull/9569/

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

PR: https://git.openjdk.org/jdk/pull/9574