Details
Description
Integer expressions which perform bitwise and can be proven to be less than or equal to either operand, as long as the compared operand is nonnegative. In other words:
(x & m) <= m, if and only if (m >= 0)
This means the lefthand test can be replaced by the simpler righthand test.
There are also offbyone versions, such as:
(x & (m1)) < m, if and only if (m > 0)
There are also unsigned versions:
(x & m) u<= m, always
(x & (m1)) u< m, if and only if (m > 0)
The optimizer should recognize these patterns. They are common in implicitly generated range checks for poweroftwo sized arrays:
int hash = ...;
int bucket = hash & (array.length1);
Entry e = array[bucket];
The range check is:
(hash & (array.length1)) u< array.length
This check can be strength reduced to:
array.length != 0
If the array is constant, or if user code has a dominating check for an empty array, this check will go away completely.
(x & m) <= m, if and only if (m >= 0)
This means the lefthand test can be replaced by the simpler righthand test.
There are also offbyone versions, such as:
(x & (m1)) < m, if and only if (m > 0)
There are also unsigned versions:
(x & m) u<= m, always
(x & (m1)) u< m, if and only if (m > 0)
The optimizer should recognize these patterns. They are common in implicitly generated range checks for poweroftwo sized arrays:
int hash = ...;
int bucket = hash & (array.length1);
Entry e = array[bucket];
The range check is:
(hash & (array.length1)) u< array.length
This check can be strength reduced to:
array.length != 0
If the array is constant, or if user code has a dominating check for an empty array, this check will go away completely.
Issue Links
 blocks

JDK8003586 HashMap arrays should be lazily allocated
 relates to

JDK8042997 Make intrinsic some or all check index/range methods

JDK7143928 (coll) Optimize for Empty HashMaps
http://cr.openjdk.java.net/~kmo/8003585/webrev.02/
Thanks!