The test (attached) for 8026049 changes exposed existing problem of how NaN values processed in 32-bit VM.

On 3/31/15 7:33 AM, Andrew Haley wrote:
" 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."

Both Server (C2) and Client (C1) VMs are affected.

32-bit Client VM (C1):

$ bin/java -client HeapByteBufferTest
Exception in thread "main" 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)

32-bit Server VM without tiered (-TieredCompilation):

$ bin/java -server -XX:-TieredCompilation HeapByteBufferTest
Exception in thread "main" java.lang.RuntimeException
    at MyByteBuffer.ck(HeapByteBufferTest.java:207)
    at MyByteBuffer.getDouble(HeapByteBufferTest.java:215)
    at HeapByteBufferTest.step(HeapByteBufferTest.java:329)
    at HeapByteBufferTest.run(HeapByteBufferTest.java:347)
    at HeapByteBufferTest.main(HeapByteBufferTest.java:362)

For some reasons Server VM only pass when TieredCompilation is enabled.