On Wed, 9 Mar 2022 22:52:41 GMT, Mandy Chung <mch...@openjdk.org> wrote:

> A simple patch to call `Objects.requireNonNull(recv)` for an explicit null 
> receiver check rather than NPE thrown by `Object::getClass`.  The message of 
> NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be 
> helpful but not in this case.

Historically I've found that `Objects.requireNonNull` compile down to be 
roughly equivalent to an implicit null check as long as a NPE is actually never 
thrown, see https://bugs.openjdk.java.net/browse/JDK-8042127 

With the recent change to force-inline `requireNonNull` the profile pollution 
part of this issue might no longer be relevant. I'll see if I can carve out 
time to do some experiments to revisit and perhaps even close out that old bug, 
but I don't think this is much to worry about for this change since provoking 
such NPEs should be rare in production settings. Always a risk adding explicit 
calls, of course: A few added cycles on startup, a few extra bytecode that 
_could_ interfere with inlining of the `checkReceiver` method.. 

I suggest a quick sanity run of our reflection (micro)benchmarks

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

PR: https://git.openjdk.java.net/jdk/pull/7766

Reply via email to