RFR: 8256056: Deoptimization stub doesn't save vector registers on x86

Vladimir Ivanov vlivanov at openjdk.java.net
Wed Nov 11 22:18:58 UTC 2020


On Tue, 10 Nov 2020 00:40:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> We did record that compiled code has wide vectors.
> May be we need specialized depot stub for 512 bits vectors

As we discussed with Sandhya, it is doable, but will introduce additional complexity. And benefits are not clear: deoptimization is far from performace critical.

I made an artificial experiment and composed a micro-benchmark which performs 100k deoptimizations in a row without triggering any recompilations. The results (on a Skylake server) are:
-XX:AVX              =3       =2      =0
save_vectors=OFF     4,6s     4,4s    4,4s
save_vectors=ON      5,5s     4,4s    4,4s
Saving full ZMM0-31 register state adds ~20% of execution time when continuously deoptimizing trivial method (just a single call), but when lazy deoptimization behaves normally (deoptimized code is thrown away along the way), there's basically no difference in scores because the time is spent in interpreter waiting for recompiled code to arrive.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1134


More information about the hotspot-compiler-dev mailing list