RFR: 8234160: ZGC: Enable optimized mitigation for Intel jcc erratum in C2 load barrier

[Vladimir Ivanov]

Thanks for taking care of it, Erik.

Overall, the approach you chose looks promising.

I'll let Intel folks to comment on the details of CPU model dispatching 
in VM_Version::compute_has_intel_jcc_erratum().

As an alternative solution, you could just align instructions on 
8/16-byte boundary (for 5 and 10 byte instruction sequencies 
respectively). It'll definitely need more padding, but it looks easier 
to implement as well. Do you consider additional padding as risky from 
performance perspective?

Regarding the implementation itself, it looks like MacroAssembler is the 
best place for it.

There are 3 parts (mostly independent) of the fix you put in the single 
place: what to do (how much padding needed), where to do (what code is 
affected), and when to apply it (based on whether hardware is affected 
or not).

Even if you want to start with ZGC load barrier, it would be nice to 
factor the machinery in such a way that it's easy to apply it in the new 
code.

For example, AbstractAssembler already holds some state which is managed 
in RAII-style (e.g., InstructionMark and ShortBranchVerifier).

You could introduce a new capability in MacroAssembler which 
conditionally pads jumps and conditional jumps.

I'm fine with doing the full refactoring later, but it would be nice to 
do first steps in that direction right away.

Best regards,
Vladimir Ivanov

On 19.11.2019 17:20, erik.osterlund at oracle.com wrote:
> Hi,
> 
> Intel released an erratum (SKX102) which causes "unexpected system 
> behaviour" when branches
> (including fused conditional branches) cross or end at 64 byte boundaries.
> They are mitigating this by rolling out microcode updates that disable 
> micro op caching for
> conditional branches that cross or end at 32 byte boundaries. The 
> mitigation can cause
> performance regressions, unless affected branches are aligned properly.
> 
> The erratum and its mitigation are described in more detail in this 
> document published by Intel:
> https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf 
> 
> 
> My intention for this patch is to introduce the infrastructure to 
> determine that we may
> have an affected CPU, and mitigate this by aligning the most important 
> branch in the whole
> JVM: the ZGC load barrier fast path check. Perhaps similar methodology 
> can be reused later
> to solve this for other performance critical code, but that is outside 
> the scope of this CR.
> 
> The sprinkling of nops do not seem to cause regressions in workloads I 
> have tried, given a
> machine without the JCC mitigations.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8234160
> 
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8234160/webrev.00/
> 
> Thanks,
> /Erik