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

[Vladimir Kozlov]

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.
>