RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v2]
David Holmes
dholmes at openjdk.org
Fri Mar 17 05:40:23 UTC 2023
On Thu, 16 Mar 2023 20:02:56 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:
>> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not.
>>
>> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size.
>> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly.
>>
>> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>
> load_klass now emits null check and other platforms supported
If we read `null_check` as "maybe perform a null check" then I can imagine there are places where we definitely do not need a null check and so can elide the call. However, I am far more skeptical there there are places where `null_check` does nothing and we are actually missing a null check - that seems unlikely (not impossible of course). And it may be that people see `null_check` and don't realize they need to read it as `maybe perform a null check` and so have used the wrong code, but ...
Given the very recent changes to `load_klass_null_check` I think we need some input from @rkennke and @coleenp .
-------------
PR: https://git.openjdk.org/jdk/pull/13026
More information about the hotspot-runtime-dev
mailing list