8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

[Andrew Haley]

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.