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

[Andrew Haley]

On Fri, 2 Jan 2026 15:39:50 GMT, Evgeny Astigeevich <eastigeevich 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.

Ah, I see. So it looks like we'll have to maintain two entirely different bodies of code to do the cache management. That will be a recurring pain, and is disappointing.

> 
> 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)

That's useful. It's worth taking advantage of cache-coherent implementations (when they're not broken!) by not emitting unnecessary instructions.

>     * [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)

Thanks. That's a good read, but no surprises. I'm fairly sure we've been doing most of that for as long as the port has existed.

> 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?

Probably not,  but I've been working on a patch to minimize the invalidation we do today.

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

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