[9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

[John Rose]

On Jul 9, 2014, at 3:14 AM, Paul Sandoz <paul.sandoz at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140709/00f5ed2c/attachment.html>