On Jul 9, 2014, at 3:14 AM, Paul Sandoz <paul.san...@oracle.com> wrote:

> 
> I quickly verified the fold up does as you expect. Also, if i do the 
> following the null check goes away:
> 
> ...
> 
>   void testLoop() {
>       for (int i = 0; i < 1000000; i++) {
>           testLoopOne(a);
>           testLoopOne(snull);
>       }
>   }

Good observation.  So rather than missing a null-case fold-up (good it's not!), 
the optimizer is speculating not-nullness (based on profile) and adding a test. 
 (Either the test is being used for a downstream optimization, or else the test 
is not being detected as useless and removed—which would be bad!.)

> I am probably obsessing too much over some micro/nano-benchmarks,

(Hi, I'm John and I'm a micro-obsess-aholic.)

> but i am wondering if this could cause some unwanted de-opt/recompilation 
> effects when all is good with no null values then suddenly a null triggers 
> de-optimization.

Besides jumping after the micro-benchmark and chewing on the optimizer until 
the code shrinks, there are two other things we can do:

1. Mentally file the issue and watch real benchmarks for evidence of the 
problem.  (This works pretty well, provided enough time and focus, and provided 
enough people have some consciousness of the optimizer's workings.)

2. Create a self-test and check it into the test base.  It could be either a 
unit test of assertion.  In this case, I don't see an easy way to do it, but 
creating clever permanent tests almost always pays off much better than 
cleverly pounding on the micro-benchmark of the moment.

— John

Reply via email to