This is found during VarHandles work. There, we need to convert booleans to integers on a fast path. Even though JLS does not specify the widening conversion from boolean to integer, runtime can still optimize some code shapes as such, knowing "true" is 1, and "false" is 0. So, this can be optimized:

  int i = (boolean) b ? 1 : 0

to:

  int i = (boolean) widen(b)

Indeed, this happens in current HotSpot, except for a single case, where one of the branches is unlikely. Then, we have the actual branch, the fast path after the branch, and the uncommon trap on the unlikely branch. This deconstructs the optimization. This does not seem to be a corner case, since we would generally try to avoid contaminating branch profile, and this would set us up for a stable "boolean" value. In other words, this is a weird case where branch pollution *helps* performance.

Benchmark + some analysis:
 http://cr.openjdk.java.net/~shade/8130447/Bool2Int.java

Runnable JAR:
 http://cr.openjdk.java.net/~shade/8130447/benchmarks.jar