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

[Evgeny Astigeevich]

On Wed, 3 Dec 2025 15:54:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Honestly, this looks fragile? We can go into nmethods patching for some other reason, not for patching oops.

For GCs on ARM64, I found only patching `nmethod::fix_oop_relocations` and patching ZGC barriers. This may be because `mustIterateImmediateOopsInCode` return false on ARM64. We will need to add support of instructions modified through `OopClosure::do_oop`.

> Is there a substantial loss is doing icache invalidation without checking for the existence of interesting oops? Do you have an idea how many methods this filters?

https://github.com/openjdk/jdk/pull/28328#issuecomment-3558673810

Axel (@xmas92) saw some SpecJVM regressions. I think they might be caused by the increased number of icache invalidation. We had not patched methods, no icache invalidation, before this PR and started always-icache invalidation after this PR. I will be checking SpecJVM, SpecJBB and other benchmarks (dacapo, renaissance).

I might check if the following approach does not have much overhead:
- In `nmethod::fix_oop_relocations`

ICacheInvalidationContext icic(UseDeferredICacheInvalidation : ICacheInvalidation::DEFERRED ? ICacheInvalidation::IMMEDIATE);
bool patching_code = false;
while (iter.next()) {
...
patching_code = reloc->fix_oop_relocation();
...
patching_code = reloc->fix_metadata_relocation();
}
If (icic.mode() ==  ICacheInvalidation::DEFERRED && !patching_code) {
  icic.set_mode(ICacheInvalidation::NOT_NEEDED);
}


If it works, it will reduce amount of changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2586934914