-
Bug
-
Resolution: Fixed
-
P4
-
24
-
b20
-
riscv
-
linux
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8342474 | 23.0.2 | Gui Cao | P4 | Resolved | Fixed | b03 |
JDK-8342532 | 21.0.6 | Gui Cao | P4 | Resolved | Fixed | b01 |
ZStoreBarrierStubC2 (ZBarriersetAssembler::generate_c2_store_barrier_stub) clobbers rflags (the t1 register) on riscv [1].
And ZStoreBarrierStubC2 is used by z_store_barrier in file gc/z/z_riscv.ad. But the calling instructs in the same ad file
didn't list the rflags as being killed. As the call chain is not simple, this kind of problem could go silently unnoticed.
I would suggest we add clobbering of rflags for all gc-related C2 instructs. This would help reduce the risk of another
PR: https://github.com/openjdk/jdk/pull/21406 which touches g1/x/z prefering t1 for performance reasons.
[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp#L746
And ZStoreBarrierStubC2 is used by z_store_barrier in file gc/z/z_riscv.ad. But the calling instructs in the same ad file
didn't list the rflags as being killed. As the call chain is not simple, this kind of problem could go silently unnoticed.
I would suggest we add clobbering of rflags for all gc-related C2 instructs. This would help reduce the risk of another
PR: https://github.com/openjdk/jdk/pull/21406 which touches g1/x/z prefering t1 for performance reasons.
[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp#L746
- backported by
-
JDK-8342474 RISC-V: ZStoreBarrierStubC2 clobbers rflags
- Resolved
-
JDK-8342532 RISC-V: ZStoreBarrierStubC2 clobbers rflags
- Resolved
- links to
-
Commit(master) openjdk/jdk21u-dev/f19e69a9
-
Commit(master) openjdk/jdk23u/56fcf0b1
-
Commit(master) openjdk/jdk/a601cd2e
-
Review(master) openjdk/jdk21u-dev/1059
-
Review(master) openjdk/jdk23u/176
-
Review(master) openjdk/jdk/21485
(3 links to)