RFR: 8261837: SIGSEGV in ciVirtualCallTypeData::translate_from

[Dean Long]

On Mon, 20 Nov 2023 22:42:41 GMT, Dean Long <dlong at openjdk.org> wrote:

> Type profiling code based on the x86 implementation uses XOR to check if the MDO value matches the klass, then later stores that XORed value into the MDO if the MDO value was 0.  However, there is a race here if we reload the MDO value to check for 0, resulting in storing OBJ_KLASS XOR MDO_KLASS back to the MDO.
> 
> I took a stab at riscv, but I don't have a way to test it.

Moved to Draft.  There is no rscratch1 register on 32-bit x86.

@vnkozlov, you might want to wait until the 32-bit x86 code is fixed before reviewing.  If I can't find an extra temp register to use, I'll need to make more significant changes.

pseudo-code of the bug:

klass = obj->klass();
mdo_klass = *mdo_addr;
// low 2 bits: null_seen, unknown_type
// case 1: klass unset
// we want (klass | (mdo_klass & 3)) if md_addr is empty or null_seen,
// XOR gives same result as OR if klass has low bits 0 and md_addr has
// high bits 0.
// case 2: klass already set and matches obj klass
// (klass ^ mdo_klass) & ~3 == 0 means klasses match 
new_klass = klass ^ mdo_klass;
if ((new_klass & ~3) == 0) {
  // match, do nothing
} else if (*mdo_addr == 0 || *mdo_addr == null_seen) {
  // XXX Oops, *mdo_addr could have changed, which means instead of the value
  // (klass | (mdo_klass & 3))
  // we might have instead
  // klass ^ mdo_klass
  *mdo_addr = new_klass;
}

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

PR Comment: https://git.openjdk.org/jdk/pull/16750#issuecomment-1819988419
PR Comment: https://git.openjdk.org/jdk/pull/16750#issuecomment-1820149602
PR Comment: https://git.openjdk.org/jdk/pull/16750#issuecomment-1820163783