Java if statement structure and instruction pipelining

Question

Question: This is more for curiosity's sake than anything else. If I have a Java if/else statement, and I know that one of the branches of the 'if/else' statement will be taken significantly more often than the other branch, can the way I order the two branches provide a hint to the JIT compiler that results in better performance?

Background: In my simplistic view of computer architecture an 'if/else' statement gets translated to, among other things, a conditional jump instruction followed by the instructions that should be executed if the jump wasn't executed. Somewhere else in memory would be the the code that the jump was targeting. As I understand it, the CPU loads instructions sequentially to the extent it can (I'm sure I'm overlooking the branch predictor here), and the non-jump path has a higher chance of being loaded into the instruction cache and the CPU's instruction pipeline.

Question Restated: Can a reasoned ordering of an if/else statement's branches increase the possibility that the often-executed code immediately follows the conditional jump instruction which would render the code more friendly to both the cache and the pipeline?

Reality: I wouldn't be surprised to hear that the JIT compiler is such a complicated piece of software that after all the instruction reordering, register allocation, and other bookkeeping it does, it can't make such guarantees.

Most of my 'if/else' statements will go un-executed so I wouldn't do this everywhere. Additionally, many times I will guess wrong about which branch will be executed more frequently and end up actually hurting performance.

I'd like to think that such a simple thing as being intentional with branch ordering would not be considered premature optimization but if it is, I'll only mess with the ordering if a profiler shows me the code is slow.

Thanks!

Answer 1

No.

You can't. You don't need to.

It makes some sense for a compiler, as it can translate

if (improbable) {
    doSomething();
} else {
    doSomethingElse();
}
doMoreThings();
return;

into (pseudocode)

if (improbable) goto away
doSomething()
back: doMoreThings()
return
away: doSomethingElse()
goto back

so that the more probable path is streamlined. An AOT compiler could rely on the provided information.

You don't need to. But such things does the Java JIT compiler all the time after it collects statistics. Here, javac is irrelevant as the bytecode gets executed a few times by the interpreter, which is slow, but good enough for parts executed rarely and also good enough for collecting statistics. Usually, these statistics are better than what the programmer may supply, but what matters more: They get collected for every time-relevant piece of code. It's actually more complicated, as there are C1 and C2 compilers there...

You can't. There's no standardized way of expressing this in the bytecode. Moreover, the optimizer converts the code in an internal representation and such details get lost.

premature optimization Forget it. The compiler can do much more complicated things pretty well. Some low level optimizations still make sense, but only in very extreme cases. Go for clean code and maybe some high-level optimization, if needed.