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:

>> Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
>> 
>>  - Fix linux-cross-compile build aarch64
>>  - Merge branch 'master' into JDK-8370947
>>  - Remove trailing whitespaces
>>  - Add support of deferred icache invalidation to other GCs and JIT
>>  - Add UseDeferredICacheInvalidation to defer invalidation on CPU with hardware cache coherence
>>  - Add jtreg test
>>  - Fix linux-cross-compile aarch64 build
>>  - Fix regressions for Java methods without field accesses
>>  - Fix code style
>>  - Correct ifdef; Add dsb after ic
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/3d54a802...4b04496f
>
> src/hotspot/share/asm/codeBuffer.cpp line 371:
> 
>> 369:       !((oop_Relocation*)reloc)->oop_is_immediate()) {
>> 370:     _has_non_immediate_oops = true;
>> 371:   }
> 
> Honestly, this looks fragile? We can go into nmethods patching for some other reason, not for patching oops.
> 
> Also, we still might need to go and patch immediate oops? I see this:
> 
> 
>   // Instruct loadConP of x86_64.ad places oops in code that are not also
>   // listed in the oop section.
>   static bool mustIterateImmediateOopsInCode() { return true; }
> 
> 
> 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?

@shipilev 
Moving `ICacheInvalidationContext icic` to `nmethod::fix_oop_relocations` works. The fragile code is no more needed.

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

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