RFR: 8364296: Set IntelJccErratumMitigation flag ergonomically

[Aleksey Shipilev]

On Wed, 30 Jul 2025 16:27:42 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> We should update the flag if we are using a computed value. Nobody else reads IntelJccErratumMitigation specifically, but we want it to be correctly shown in PrintFlagsFinal and anywhere else these flags are inspected.
> 
> 
> Intel(R) Xeon(R) Platinum 8259CL
> java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep IntelJcc
> Before:
>      bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {default}
> After:
>      bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {ergonomic}
> 
> 
> Even worse when it's actually false, but shows as true:
> 
> 
> AMD EPYC 7R13
> java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep IntelJcc
> Before:
>      bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {default}
> After:
>      bool IntelJccErratumMitigation  = false  {ARCH diagnostic} {ergonomic}

This looks fine to me as the solution to the UX problem.

Thinking out loud:

I don't know `VM_Version::_has_intel_jcc_erratum` field bears any reasonable weight at this point. That said, I think the guidance I heard from @vnkozlov once is that checking the flag directly instead of calling into `VM_Version` is frowned upon. This would be somewhat important in Leyden.

But maybe we should go and redefine `VM_Version::has_intel_jcc_erratum` to return the `IntelJccErratumMitigation` value as well. That would require JVMCI folks to poll the JVM flag directly instead of going via VMStructs. Also somewhat busy-work-ish. 

So I am approving this as an MVP that solves the UX problem and does not prompt any additional work.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26560#pullrequestreview-3072899137