RFR: 8260355: AArch64: deoptimization stub should save vector registers

[Vladimir Ivanov]

On Thu, 28 Jan 2021 11:17:16 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>> src/hotspot/share/prims/vectorSupport.cpp line 138:
>> 
>>> 136: 
>>> 137:     for (int i = 0; i < num_elem; i++) {
>>> 138:       bool contiguous = X86_ONLY(false) NOT_X86(true);
>> 
>> I don't like this change. It's not x86-specific, but SVE-specific code. What is broken here is `VMReg::next()` doesn't work properly for `VecA` registers. And, as a result, it makes `RegisterMap::location(VMReg)` unusable as well. 
>> 
>> So, a proper fix should address that instead. If there's no way to save `VMReg::next()` and `RegisterMap::location(VMReg)`, then new cross-platform API should be introduced and `VectorSupport::allocate_vector_payload_helper()` migrated to it.
>
> For Arm NEON (and PPC) we don't set VMReg::next() in oopmap either, and their vector slots are contiguous, so that's x86-specific? But yes, NEON can also generate correct full oopmap as for fixed vector size. For SVE, I have no idea to have proper VMReg::next() support, so Nick's solution looks good to me. Regarding to introducing new cross-platform API, which API do you mean? If we could have some better api, that would be perfect. Currently, allocate_vector_payload_helper() is the only one I can see that is vector related for RegisterMap::location() call.

Probably, x86 unique in using non-contiguous representation for vector values, but it doesn't make the code in question x86-specific. AArch64 is the only user of`VecA` and `VecA` is the only register type which has a mismatch in size between in-memory and RegMask representation. So, I conclude it is AArch64/SVE-specific.

On x86 RegisterMap isn't fully populated for vector registers as well, but there's`RegisterMap::pd_location()` to cover that.

Regarding new API, I mean the alternative to `VMReg::next()`/`RegisterMap::location(VMReg)` which is able to handle `VecA` case well. As Nick pointed out earlier, the problem with `VecA` is that there's no `VMReg` representation for all the slots which comprise the register value. 

Either enhancing `VMReg::next(int)` to produce special values for `VecA` case or introducing `RegisterMap::location(VMReg base_reg, int slot)` is a better way to handle the problem.

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

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