On 02/19/2015 06:17 PM, Peter Levart wrote: > On 02/19/2015 04:02 PM, Aleksey Shipilev wrote: >>> >Hi Aleksey, >>> > >>> >Is profile pollution problem already fixed? Can Objects.requireNonNull >>> >be used in performance critical code without fear of performance >>> >regression? >> What profile pollution? Objects.requireNonNull is a static method. See >> also the link in bug description: >> http://cr.openjdk.java.net/~shade/scratch/NullChecks.java >> >> -Aleksey. >> > > Remi described it here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026669.html
Okay, Remi's premise is that implicit null check is much cheaper than an explicit one when it's not tripped. It's then seem to extend to mean that pessimistically inflating the nullcheck into the explicit one costs performance, and therefore one should avoid requireNonNull. But then we all got confused with benchmarks and whatnot. The benchmark from JDK-8047127 actually measures the cost of raising the exceptions, where getClass and friends are profoundly cheating: https://bugs.openjdk.java.net/browse/JDK-8042127#comment-13611255 http://cr.openjdk.java.net/~shade/8042127/NullCheckMix.java However, if you do the actual benchmark that compares explicit NP checks vs implicit NP checks (that benchmark is very tricky to get right): http://cr.openjdk.java.net/~shade/scratch/NullCheckPollution.java Benchmark (count) (pollute) Mode Cnt Score Error Units NCP.testExplicit 100000 false avgt 50 1.813 ± 0.004 ns/op NCP.testExplicit 100000 true avgt 50 1.891 ± 0.029 ns/op NCP.testImplicit 100000 false avgt 50 1.812 ± 0.003 ns/op NCP.testImplicit 100000 true avgt 50 1.811 ± 0.001 ns/op There, testExplicit with pollution is the only one that has explicit test+branch. The difference is minuscule (< 1/3 of CPU cycle), and I would choose not to care, even for JDK code. That test is crafted specifically so that compiler could not disambiguate different callers. In real life, a Sufficiently Smart Compiler may inline the callees and reprofile in the context of caller. But even in the absence of that, the performance hit would be buried in everything else. In the places where you *need* the every last bit of performance, you can do the by-hand explicit nullcheck. (Note that it is not a good idea to do getClass anyway, because of JDK-8073432). Thanks, -Aleksey.
