[jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in 4 files

[Boris Ulasevich]

On Mon, 20 Dec 2021 20:50:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A small refactoring to resolve a Parfait complaint about the return value from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)`
> on AARCH64. The logic that supports returning `nullptr` as the target addr for
> a particular instruction is moved from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)` to
> `MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn)`.
> A couple of `target_addr_for_insn()` call sites that can tolerate a `nullptr` are
> converted to use `target_addr_for_insn_allow_null_ret()`.
> 
> This fix has been tested with Mach5 Tier[1-3].

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 286:

> 284:                    + (uint64_t(Instruction_aarch64::extract(insns[1], 20, 5)) << 16)
> 285:                    + (uint64_t(Instruction_aarch64::extract(insns[2], 20, 5)) << 32));
> 286:   } else if (Instruction_aarch64::extract(insn, 31, 22) == 0b1011100101 &&

It must be a check for safePoint poll: ldrw zr, polling_page. Technically, the target address for this instruction is zero and the function is correct. I am not sure Parfait is right in his complaints. After all, does this code ever works? That is, if you remove it, will the SholdNotReachHere below fire?

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

PR: https://git.openjdk.java.net/jdk18/pull/51