RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1

[Igor Veresov]

On Wed, 18 Aug 2021 12:37:00 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
> 
> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>> __ move(addr, tmp);
> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
> The fix is to check if it is is_oop() and call the mov appropriately.
> 
> No issues found in local testing and Mach5 tier1-3

I think we have to somehow tell the register allocator not to spill arguments of type converting moves.  We already have some logic there to prevent spills in logic and arithmetic involving T_OBJECT: https://github.com/openjdk/jdk/blob/d732c3091fea0a7c6d6767227de89002564504e5/src/hotspot/share/c1/c1_LinearScan.cpp#L1135
Perhaps we should also detect the conversion case when ( `src` and `dst` ) are of different types and force both to be in registers?  Basically insert some logic here (reg-reg move):
https://github.com/openjdk/jdk/blob/d732c3091fea0a7c6d6767227de89002564504e5/src/hotspot/share/c1/c1_LinearScan.cpp#L1068
Check the types, and if it's the T_OBJECT->T_LONG situation  return `mustHaveRegister` ?

May be there is better solution, but that's the first thing that came to mind.

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

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