[9] RFR(M): 8076373: In 32-bit VM interpreter and compiled code process signaling NaN values inconsistently

Zoltán Majó zoltan.majo at oracle.com
Fri Aug 7 13:14:44 UTC 2015


please review the following patch for JDK-8076373.

Bug: https://bugs.openjdk.java.net/browse/JDK-8076373

Problem: On x86_32 systems with XMM instructions available, the 
compilers and the interpreter behave inconsistently as far as signalling 
NaNs (sNaNs) are concerned. For example, the following statement||

start == doubleToRawLongBits(longBitsToDouble(start))

can be true or false, assuming that the variable 'start' contains a bit 
pattern corresponding to a sNaN.

The result is true if the statement is executed by compiled code and 
longBitsToDouble/doubleToRawLongBits have been replaced by compiler 
intrinsics. The result is false if the native library version of the 
functions is used (either by compiled or by interpreted code).

The inconsistency happens because the interpreter/native ABI relies on 
x87 instructions to process floating point numbers, whereas the 
compilers use XMM registers for the same purpose. x87 instructions 
silently convert signaling NaNs to quiet NaNs, XMM instructions preserve 

- Add intrinsics (stubs) for java.lang.Float.intBitsToFloat, 
java.lang.Float.floatToRawIntBits, java.lang.Double.longBitsToDouble, 
and java.lang.Double.doubleToRawLongBits. The stubs use XMM registers 
and therefore preserve sNaNs. The stubs are used by both the interpreter 
and the compilers.
- Change the interpreter to use XMM registers instead of x87 registers 
to internally cache floating point values. As a result, sNaNs are 
preserved within the interpreter.


- JPRT run, testset hotspot (including the newly added test, 
NaNTest.java); all tests pass;
- all JTREG tests in hotspot/test on x86_32 and x86_64; all tests pass 
that pass with the default version of the VM.

Thank you and best regards,


More information about the hotspot-compiler-dev mailing list