[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
Hi,
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
sNaNs.
Solution:
- 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.
Webrev:
http://cr.openjdk.java.net/~zmajo/8076373/webrev.00/
Testing:
- 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,
Zoltan
More information about the hotspot-compiler-dev
mailing list