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

[Viswanathan, Sandhya]

Hi Vladimir/Eric,

The CPU model list in VM_Version::compute_has_intel_jcc_erratum() looks correct and is per section 4.0 of the document:
https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf

Best Regards,
Sandhya

 

-----Original Message-----
From: hotspot-compiler-dev <hotspot-compiler-dev-bounces at openjdk.java.net> On Behalf Of Vladimir Ivanov
Sent: Thursday, November 21, 2019 3:02 AM
To: erik.osterlund at oracle.com; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
Subject: Re: RFR: 8234160: ZGC: Enable optimized mitigation for Intel jcc erratum in C2 load barrier

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/m
> itigations-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