RFR: 8296448: RISC-V: Fix temp usages of heapbase register which is killed by MacroAssembler::en/decode_klass_not_null

Xiaolin Zheng xlinzheng at openjdk.org
Mon Nov 7 04:10:34 UTC 2022


Please see the JBS issue for more crash details.

To reproduce using a cross-compiled build:

# dump one cds-nocoops.jsa
<java> -XX:-UseCompressedOops -XX:+UseCompressedClassPointers -Xlog:cds* -version

# reproduce
<java> -XX:-UseCompressedOops -XX:+UseCompressedClassPointers -Xshare:on -XX:-TieredCompilation -Xlog:cds* -Xlog:gc+metaspace=info -Xshare:on -jar renaissance-gpl-0.14.1.jar -r 1 movie-lens


`MacroAssembler::en/decode_klass_not_null` uses the heapbase register as a temp register in the interpreter, which may kill the in-use value when enabling C2 compilation and `UseCompressedClassPointers` meanwhile disabling `UseCompressedOops`. C1 won't have this issue for the xheapbase is not its allocation candidate. When CDS is enabled, the narrow klass base is mapped to some address like `0x0000000800000000`, so `MacroAssembler::decode_klass_not_null`, which lacks registers, will use `xheapbase` as a temp to load the klass base and kill the register in the interpreter. So adding a `-XX:+DeoptimizeALot` can speedily reproduce the issue.

To solve this, we shall decouple the xheapbase used as a temp register in `MacroAssembler::en/decode_klass_not_null`. AArch64 has advanced instructions so one register is enough to handle the logic. But in RISC-V we require at least two.

This patch introduces another argument `tmp` to related functions to decouple and eliminate such heapbase usages. One thing that deserves noticing is the `cmp_klass` case, which usually gets used at the beginning of a method entry when t1 is used as ic holder klass and t0 is occupied there. These points are special for nearly all registers except argument registers and regs used for special purposes (thread register, etc.) can be used. I propose to use a call-clobbered t2 register here, to keep aligning the i2c2i_adapter logic[1].

Tested hotspot tier1~4 on QEMU; jdk tier1~tier2 and hotspot tier1~tier2 on my Hifive unmatched board, and the reproducible movie-lens benchmark.

Thanks,
Xiaolin

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp#L629

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

Commit messages:
 - Simply rename tmp -> tmp1
 - Remove useless
 - Refactor
 - Fix

Changes: https://git.openjdk.org/jdk/pull/11010/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11010&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296448
  Stats: 46 lines in 8 files changed: 8 ins; 6 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/11010.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11010/head:pull/11010

PR: https://git.openjdk.org/jdk/pull/11010


More information about the hotspot-dev mailing list