StrictMath performance improvement not ported to Math?

Martin Desruisseaux martin.desruisseaux at
Fri Nov 18 14:29:38 UTC 2011

Hello all

On December 1, 2010, "darcy" committed a slight performance improvement to the 
StrictMath.min/max methods with floating point arguments (commit 8aabca72877c). 
The calls to the doubleToLongBits(double) method were replaced by calls to the 
doubleToRawLongBits(double) method, and similarly for the float type. Since the 
call to doubleToLongBits was used only in order to determine if an argument was 
negative zero, and since NaN can not map to the bits pattern of -0.0, the extra 
cost of collapsing all NaN values to a single canonical NaN (which is the only 
difference between doubleToLongBits and doubleToRawLongBits) was unnecessary.

However this improvement has not been ported from StrictMath to Math; the more 
widely-used Math class still invokes the (presumed) slower 
doubleToLongBits(double) method. Actually it appears that most Math / StrictMath 
method implementations delegate to the other class: some Math methods delegates 
to StrictMath (mostly the methods backed by native code), and some StrictMath 
methods delegate to Math (mostly the methods implemented in pure-Java). The 
min/max methods are an exception; their implementation is copied in both 
classes. Maybe this explain why the code was updated in only one class and not 
the other?

In the patch submitted below, I propose the following changes:

1) Ported the doubleToLongBits --> doubleToRawLongBits changes from StrictMath 
to Math.

2) Replaced StrictMath implementations by calls to Math, in order to reduce the 
risk that the code of only one class is updated in the future.

3) In if statements, replaced:

       (a == 0.0d) && (Double.doubleToLongBits(a) == negativeZeroDoubleBits)
       (Double.doubleToLongBits(a) == negativeZeroDoubleBits)

since the later implies the former.

4) Moved the check for (a != a) from the method beginning to the last statement, 
which is tested only if (a <= b) were false rather than tested unconditionally 
in every cases. I'm not sure if it make a real performance difference however.

Webrev link:



More information about the core-libs-dev mailing list