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

[Evgeny Astigeevich]

On Thu, 19 Feb 2026 15:51:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do fullGC when multiple threads execute test methods
>
> src/hotspot/cpu/aarch64/globals_aarch64.hpp line 130:
> 
>> 128:   product(bool, AlwaysMergeDMB, true, DIAGNOSTIC,                       \
>> 129:           "Always merge DMB instructions in code emission")             \
>> 130:   product(bool, NeoverseN1Errata1542419, false, DIAGNOSTIC,             \
> 
> Sounds like a mouthful with these numbers? We have a mitigations for Intel like that, see `IntelJccErratumMitigation`, so IMO it makes sense to match that. For example, `NeoverseICacheErratumMitigation`? This also captures the intent: we are _mitigating_ the errata.

Renamed to `NeoverseN1ICacheErratumMitigation`.

> src/hotspot/share/code/nmethod.cpp line 2084:
> 
>> 2082: }
>> 2083: 
>> 2084: void nmethod::fix_non_immediate_oop_relocations(ICacheInvalidationContext* icic) {
> 
> So this almost duplicates `fix_all_oop_relocations()`, correct? What do we gain from doing so? The old code has boolean flag that gates processing immediates or not, it sounds less error-prone to keep it that way?

Returned back to the version with the flag. Removed duplication.

> src/hotspot/share/gc/g1/g1NMethodClosure.cpp line 90:
> 
>> 88:   }
>> 89: 
>> 90:   nm->fix_non_immediate_oop_relocations();
> 
> I don't quite understand this replacement. Why can't/shouldn't we call `fix_all_oop_relocations()` here, so we get to the same code? I understand Shenandoah s `_has_non_immed_oops` in this check, but G1 does not have it. 
> 
> To phrase it differently, what do we _lose_ by going into `fix_all_oop_relocations()`?

Restore the old logic.

> test/hotspot/jtreg/gc/TestDeferredICacheInvalidation.java line 221:
> 
>> 219:             WB.enqueueMethodForCompilation(m, compLevel);
>> 220:             while (WB.isMethodQueuedForCompilation(m)) {
>> 221:                 Thread.onSpinWait();
> 
> Burns CPU for no reason, surely compiler would not respond in microseconds. Just do a small sleep?

Changed to sleep(100).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2842592363
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2842597684
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2842601398
PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2842609700