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

[erik.osterlund at oracle.com]

Hi Tobias,

Thanks for the review!

/Erik

On 2/21/20 2:05 PM, Tobias Hartmann wrote:
> Hi Erik,
>
> On 19.02.20 17:01, erik.osterlund at oracle.com wrote:
>> Thanks for the review. I applied your suggested polishing, and the new webrev is here:
>> http://cr.openjdk.java.net/~eosterlund/8234160/webrev.02/
> Looks good, thanks for making these changes!
>
>> Eric Caspole helped me with the evaluation (he ran a *lot* of stuff. I'm not sure if micro
>> benchmarks for those
>> specific stubs/intrinsics were run. I only know that among all the benchmarks he ran (most of them I
>> think actually
>> do something meaningful), the mitigation was effective at removing the throughput overheads that the
>> micro code introduced.
>> There were only a few examples (apart from startup-benchmarks that are out of scope for this change)
>> like some
>> XML sub-benchmark of SPECjvm2008 where a few percent were lost,comparing baseline (no micro code,
>> without my patch)
>> to the mode of having the micro code and my patch. Butnotably, the same regression existed comparing
>> the baseline
>> to a machine without the micro code and my patch.
>>
>> So it seems like the act of nop sprinkling has bloated the code cache a bit in a way that cost a few
>> percent
>> in that benchmark, as opposed to there being a sign such regression is due to missing out important
>> branches in
>> stubs/C2 intrinsics.Is it possible that some stubs are left suboptimal? Yes. But not what we have
>> seen stick out
>> in results in practice. I'm sure you can construct a program that turns this into a problem, but the
>> aim of this
>> change is to just fix "most of the problems" occurring in practice in a way that is as unintrusive
>> and correct as possible.
> Sounds good, thanks for the details.
>
> Best regards,
> Tobias