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