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

[erik.osterlund at oracle.com]

Hi Sandhya,

Thanks for verifying the magic table.

/Erik

On 11/22/19 12:58 AM, Viswanathan, Sandhya wrote:
> 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