RFR (S) 8073479: Replace obj.getClass hacks with Objects.requireNonNull

[Aleksey Shipilev]

On 02/19/2015 09:36 PM, Vitaly Davidovich wrote:
> The problem is microbenchmarking this may not tell the true story (like
> all microbenchmarks).  In this case the explicit test and branch is
> probably perfectly predicted because there's not much code.  In a bigger
> application, where the history fell out of the buffer, it'll depend on
> what static prediction is used.  Or, this branch will evict another
> useful one from the history buffer.  Not saying you're wrong in your
> suggestion to go ahead with this change, but something to keep in mind.

Noted, however the argument can be made that:
 a) that the same thing applies to getClass()-style checks for public
APIs. Once anybody calls the API method with nulls, the getClass() check
would inflate into explicit branch, and then you face the same branch
predictor behavior;
 b) the branch misprediction for otherwise stable branch is by
construction transient, and CPUs should re-learn quickly if we keep on
calling the method. If we don't, then the cost of branch mispredict is
not important to begin with. This should be taken with a grain of salt,
because only a selected few (definitely not me, quite probably no one
except HW engineers) know how exactly branch predictors work.

That said, the reasonable way you can address these (micro)things in
compiler is to intrinsify Object.requireNonNull to resist the profile
pollution and emit the implicit null check unconditionally. But I submit
that class library should not care about low-probability mispredict, and
do the thing that clearly declares intent. The performance cost of
profile pollution, is negligible for our cases.

-Aleksey.