The relativized locals value is supposed to contain the distance between the frame pointer and the local variables in an interpreter frame, expressed in number of words. It typically contains the value "frame::sender_sp_offset + padding + max_locals - 1"

On most architectures sender_sp_offset is 2. This gives us the value "1 + padding + max_locals", which is always greater or equal to 1.

However on RISC-V the value of frame::sender_sp_offset is 0, which means that if we don't have any padding and no local variables we end up with a relativized_locals value of -1.

When generate_fixed_frame() calculates the relativized_locals value it subtracts the frame pointer from the xlocals and then logically shifts the result right by Interpreter::logStackElementSize (to convert it into a word index).

This works fine on all platforms (except RISC-V), because the subtraction will never become negative. But since the subtraction can end up negative on RISC-V, the shift instruction must be a arithmetic-shift-right (not a logical-shift-right) to preserve the sign and not end up with a very large positive index.

This is currently not a real problem since the relativized_locals value is not used if max_local is zero, which is the only case the value is wrong.

It is however a real problem when implementing JDK-8300197.

The bug was introduced in JDK-8299795 and is fixed by changing a "srli" instruction to a "srai" in generate_fixed_frame().