Strange branching performance (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Feb 10 22:02:06 PST 2014

Hi Martin,

What JDK version you are using? I see in generated code the increment instruction is moved out of the loop. Also can you try flag -XX:-BlockLayoutByFrequency? Use it with your original test from SO not your latest jmh test you sent me. I noticed that commandline flags are not passed into forked process in your jmh test.

Regards, Vladimir

On 2/8/14 1:11 PM, Martin Grajcar wrote:

Hi Vladimir!

On Sat, Feb 8, 2014 at 4:36 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote: Hi Martin, Your observation is correct. The corresponding code is next: float infrequentprob = PROBUNLIKELYMAG(3); // 0.001 // BlockLayoutByFrequency optimization moves infrequent branch // from hot path. No point in CMOV'ing in such case (110 is used // instead of 100 to take into account not exactness of float value). if (BlockLayoutByFrequency) { _infrequentprob = MAX2(infrequentprob, (float)BlockLayoutMinDiamondPercentag_e/110.0f); } // Check for highly predictable branch. No point in CMOV'ing if // we are going to predict accurately all the time. if (iff->prob < infrequentprob ||_ _iff->prob > (1.0f - infrequentprob)) return NULL; Note, BlockLayoutMinDiamondPercentag_e is default 20 so infrequentprob become 0.2 as you observed.

Yes, there's a sharp edge somewhere below 0.2. C2 moves infrequent code outside the loop (with branches out and back) to keep only hot code inside. To me it looks like there's nothing to be moved outside of the loop. Mainly because you'd hardy save anything as you'd replace the two instructions LEA (%resultreg, 1), %tmpreg CMOVEQ %tmpreg, %resultreg by a conditional jump. Saving a single instruction on the hot path and risking a branch misprediction penalty might make sense for very low probabilities like PROBUNLIKELYMAG(3), not 20%. It looks like it does not happen in your case and I need to look why. There are several conditions besides BlockLayoutByFrequency and the above code could be incorrect and needs to be fixed (or removed). Nice that you can look into it. There are a lot of attempts to eliminate branching manually like in http://grepcode.com/file/repo1.maven.org/maven2/com.google.guava/guava/15.0/com/google/common/math/IntMath.java#IntMath.gcd%28int%2Cint%29 but this is nearly always less efficient than using CMOVcc. Regards, Martin.

More information about the hotspot-compiler-dev mailing list