RFR(M): 8076373: In 32-bit VM interpreter and compiled code process signaling NaN values inconsistently
Berg, Michael C
michael.c.berg at intel.com
Fri Aug 7 20:37:54 UTC 2015
Zoltan, the code looks ok. I have reviewed it in detail.
From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
Sent: Friday, August 07, 2015 12:33 PM
To: hotspot-compiler-dev at openjdk.java.net
Subject: Re:  RFR(M): 8076373: In 32-bit VM interpreter and compiled code process signaling NaN values inconsistently
I think this is good. You need second review since changes are big and complex.
On 8/7/15 6:14 AM, Zoltán Majó wrote:
> 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
> 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.
> - 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