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

This pull request has now been integrated.

Changeset: 228e8e94
Author:    Erik Österlund <eosterlund at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/228e8e94fe048e56d5513b150060c9b54f15642c
Stats:     179 lines in 14 files changed: 121 ins; 22 del; 36 mod

8290700: Optimize AArch64 nmethod entry barriers

Reviewed-by: kvn, dlong

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

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