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

[Andrew Haley]

On Thu, 19 Feb 2026 16:13:56 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/share/code/relocInfo.cpp line 621:
> 
>> 619: 
>> 620: 
>> 621: bool metadata_Relocation::fix_metadata_relocation() {
> 
> I understand we return the status here, so that we avoid invalidation when there is no real patching work was done. Granted, it likely matches the behavior we have. But I wonder how much this buys us? If we are doing the deferred invalidation in a very broad scope, it stands to reason we would _almost definitely_ have to invalidate, and all this tracking would _nearly always_ give us the same answer, "Do invalidate"?
> 
> IOW, this might be an unnecessary complication of the interface.
> 
> _Dropping_ this change would also be more robust, in cases something somewhere _forgets_ to announce the code cache was changed? If we don't trust the downstream code about this and just summarily invalidate, it feels safer.

> @shipilev
> 
> > But I wonder how much this buys us?
> 
> SPECjvm crypto.aes is the case for this change. When I ran it on Graviton 2, 64 cores I got the following scores:
>
>     * Baseline: 1047(min), 1058(max), 1052(geomean)
> 
>     * PR: 1058(min), 1078(max), 1069(geomean), +1.6% improvement

This improvement is almost in the noise. What's the average SPECjvm improvement?

> **OPTION 1**: If we don't track code modification in `fix_oop_relocations` and assume any call of `fix_oop_relocations` requires icache invalidation, results are the following:
> 
>     * 1032(min), 1057(max), 1045(geomean), -0.7% regression

So, Options 1 and 2 are actually worse than doing nothing?

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

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