RFR: 8307625: Redundant receiver null check in LibraryCallKit::generate_method_call [v3]
Tobias Hartmann
thartmann at openjdk.org
Mon Jun 26 14:16:05 UTC 2023
On Mon, 26 Jun 2023 13:05:13 GMT, Eric Nothum <duke at openjdk.org> wrote:
>> The null_check_receiver() calls in generate_method_call are redundant as all callers of generate_method_call already perform this check. For future uses of generate_method_call a new assert is introduced that fails if the caller does not null check the receiver.
>> Also generally null_check_receiver() should be combined with stopped(), which was not the case here.
>
> Eric Nothum has updated the pull request incrementally with one additional commit since the last revision:
>
> 8307625: adding null_check_receiver() for the uninitialized case, as else only argument(1) is null checked
Just FTR: The intrinsified `Unsafe::allocateUninitializedArray0` can currently not be called with a null receiver because it's private and only ever called from `Unsafe::allocateUninitializedArray` which would throw a NPE. But to be on the safe side in case this ever changes, we should emit a null check.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14542#issuecomment-1607583619
More information about the hotspot-compiler-dev
mailing list