RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact on GCs and JIT performance [v21]

[Evgeny Astigeevich]

On Fri, 2 Jan 2026 12:07:57 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > Sure, I can see that, but is there any reason not to do this by default on all AArch64?
> > 
> > 
> > Do you mean to do this for all AArch64 OSes, not only for Linux AArch64?
> 
> In a perfect world we'd do this for all AArch64. But Linux-only would be good too. But is there any reason not to do this on all Linux systems?

IMO, a reason is that not all AArch64 might have both `ctr_el0.IDC` and `ctr_el0.DIC` set. If either of `ctr_el0.IDC`/`ctr_el0.DIC` or both are not set, we will need to use `DC`/`IC` with real addresses to clean and to invalidate caches. We will need to choose between invalidating modified instructions or the whole nmethod's code. Invalidating modified instructions will need tracking of modified instructions. Invalidating the whole nmethod does not need tracking but it can be expensive vs invalidating particular instructions.

IMO cases of Java running on AArch64 CPU where both `ctr_el0.IDC` and `ctr_el0.DIC` are not set, might be rare.

Jacob Bramley from Arm has nice blog posts about Caches and Self-Modifying Code:
- [Caches and Self-Modifying Code: Implementing `__clear_cache`](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-implementing-clear-cache)
- [Caches and Self-Modifying Code: Working with Threads](https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads)

In this PR we optimize two parts invalidating caches:
1. GCs patching code. This is invalidation of modified instructions.
2. Generation and installation of code. This is invalidation of the whole code.

The second case can be optimized for all AArch64.

Is there anything I am missing? And we can do optimized cache invalidation on all AArch64?

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

PR Comment: https://git.openjdk.org/jdk/pull/28328#issuecomment-3705607781