Bug ID: JDK-8130447 "int i = (boolean) b ? 1 : 0" is not optimized when one of the branches is unlikely

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
tbdUnresolved

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