On 03/25/2015 09:13 AM, Andrew Haley wrote: > On 24/03/15 23:40, Vladimir Kozlov wrote: > >> The test failed when run it in JPRT with 32-bit fastdebug *Client* VM >> (-client) on linux-x86: >> >> java.lang.RuntimeException >> at MyByteBuffer.ck(HeapByteBufferTest.java:201) >> at MyByteBuffer.getLong(HeapByteBufferTest.java:211) >> at HeapByteBufferTest.step(HeapByteBufferTest.java:311) >> at HeapByteBufferTest.run(HeapByteBufferTest.java:347) >> at HeapByteBufferTest.main(HeapByteBufferTest.java:362) >> >> Could be intrinsic in C1 does not work correctly? Please, look. > > I certainly will. That is odd: there's no reason I can think of why > this might happen, and I know that the test running on a server build > runs C1 code for a while so it has been tested. I guess it must be a > rare edge case.
It's not what I expected, and maybe not what you expected either. My test case fails on 32-bit x86 before any of my patches have been applied. It turns out that the problem is due to the handling of floating-point NaNs on legacy 32-bit x86 systems. The template interpreter uses 80x87 floating point but the compilers use XMM registers. XMM is transparent to all floating-point data: you can load and store any bit pattern and it is not altered. The same is not true of 80x87: if the operand of an operation is a signaling NaN, the default action is to silently convert it to a quiet NaN. This means that interpreted and compiled code will do different things with signaling NaNs. While I'm not sure if this is a specification violation, it certainly is a breach of the Write Once, Run Anywhere principle, albeit a very unimportant one. I've altered the test code so that when generating random bit patterns it never generates a signaling NaN. This makes for a clean run on 32-bit x86 systems. http://cr.openjdk.java.net/~aph/unaligned.jdk.9/ http://cr.openjdk.java.net/~aph/unaligned.hotspot.9/ Andrew.
