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

[Hohensee, Paul]

It's not just the zgc load barrier that's affected, it's every jcc and fuzed jcc (e.g., cmp/jcc and sub/jcc, because the pairs are issued on the same clock). There's a code pattern attribute called ins_alignment(<n>) in the ad file, vis

ins_attrib ins_alignment(1);    // Required alignment attribute (must
                                // be a power of 2) specifies the
                                // alignment that some part of the
                                // instruction (not necessarily the
                                // start) requires.  If > 1, a
                                // compute_padding() function must be
                                // provided for the instruction

Would it be possible to use/enhance ins_alignment() rather than do something zgc-specific?

Thanks,

Paul

On 11/19/19, 6:23 AM, "hotspot-compiler-dev on behalf of erik.osterlund at oracle.com" <hotspot-compiler-dev-bounces at openjdk.java.net on behalf of 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