On May 13, 2015, at 2:25 PM, Ivan Gerasimov <ivan.gerasi...@oracle.com> wrote: > > My third concern is this: Wouldn't it be possible to implement this type of > optimization at jvm level? > At least some conditions can automatically be combined into one. > Given the information about which execution path is expected to be fast, > hotspot should be able to quickly perform that one combined condition check > and move to the fast path in most situations.
I think this is the high-order bit: Such optimizations are done, or should be done, at the JVM level. If you can tell there's a missing JVM optimization, file a bug against the JVM JIT, and keep the clearest code style. If you can't tell, still try to keep the clean code style. HotSpot's optimizing JIT does not respond equally well to all source (bytecode) code styles; it works harder to optimize commonly encountered cases, like the simpler JMH cases in the current example. Writing strange code that seems to map to smaller or less branchy assembly code might work for one micro-version of the JVM, and then be defeated by the next micro-version. Here are two reasons "||" might be preferable to "|" in your source code: 1. The JVM interpreter profiles "||" outcomes but not "|". (Side effect of profiling branches *in the interpreter*.) 2. The C2 JIT looks for small control flow diamonds that it can turn into conditional moves or other consolidated instructions. If the "||" gets suboptimal assembly code for you, and if your code has a commonly-occuring shape, it would be better for all of us to leave the code alone and fix the optimizer. — John
