JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

Peter Levart peter.levart at gmail.com
Fri Feb 21 11:48:51 UTC 2014


On 02/21/2014 10:06 AM, Paul Sandoz wrote:
> I think we should try and use zero, as John says (alas @Stable is package private to j.l.invoke), and replace 0 with another value such as MIN_VALUE if one is unsure of the bounds:
>
>    int lsb;
>    if ((lsb = lowestSetBit) == 0) {
>      ...
>      lowestSetBit = lsb != 0 ? lsb : Integer.MIN_VALUE;
>    }
>    return lsb != Integer.MIN_VALUE : lsb ? 0;

Hm, would the following be any better or worse?

int lsb = lowestSetBit;
if (lsb <= 0) {
     if (lsb == Integer.MIN_VALUE) {
         lsb = 0;
     } else {
         ...
         lowestSetBit = lsb != 0 ? lsb : Integer.MIN_VALUE;
     }
}
return lsb;


I wonder if any of the above is better than current code that offsets 
the value space. Current code only contains a single 
compare+conditional-branch on fast-path while both of above variants 
contain more than one. Does eliminating a single add instruction on 
fast-path pay up for that? What do measurements show?


Regards, Peter




More information about the core-libs-dev mailing list