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

[Sandhya Viswanathan]

On Mon, 9 Nov 2020 21:21:51 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> If possible, it will be good to do this optionally.
>> Doing it unconditionally, the concern is the frequency drop with larger vector width.
>
>> If possible, it will be good to do this optionally.
> As I mentioned earlier, it's possible, but requires 2 variants of deopt stub and dispatching logic to choose proper one depeding on the location it is patched with. 
> 
> Deoptimization process is already expensive and execution ends up in interpreter anyway. 
> 
> Is the frequency drop such a problem in case of deopt stub to justify the increase in complexity?
> Also, I'd like to point out that on older CPUs with AVX512 supported (like Skylake) AVX=3 is turned off by default to avoid generating EVEX-encoded instructions on CPUs which have frequency scaling issues. So, if AVX=3 is specified, there are already many places (which are more performance sensitive IMO) with EVEX-encoded instructions.

May be not. Let us go with your solution and we can revisit if the performance runs show otherwise.

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

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