Thank you, Andrew
I will file a separate bug to address this issue - Interpreter and compiled
code should produce the same result!
And I will push your changes today.
Regards,
Vladimir
On 3/31/15 7:33 AM, Andrew Haley wrote:
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.
