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

Tobias Hartmann tobias.hartmann at oracle.com
Fri Feb 21 13:05:00 UTC 2020


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


More information about the hotspot-compiler-dev mailing list