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
