RFR: 8290700: Optimize AArch64 nmethod entry barriers

[Erik Österlund]

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.

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

Depends on: https://git.openjdk.org/jdk/pull/9569

Commit messages:
 - 8290700: Optimize AArch64 nmethod entry barriers

Changes: https://git.openjdk.org/jdk/pull/9574/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9574&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290700
  Stats: 178 lines in 14 files changed: 120 ins; 22 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/9574.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9574/head:pull/9574

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