Report a bug in HotSpot

[Krystal Mo]

Hi Coleen,

Thank you for the reply.

Yes, I know that flag, but it doesn't fix the problem demonstrated in 
the first test case.
Running that test case with this flag will still show "Double a is NaN" 
on 32-bit JDK7u9 on Ubuntu 12.04. It's not about the FPU control word.

Regards,
Kris

On 2012/11/27 22:53, Coleen Phillimore wrote:
>
> We have this flag for this problem:
>
>   product(bool, AlwaysRestoreFPU, 
> false,                                    \
>           "Restore the FPU control word after every JNI call 
> (expensive)")  \
> \
>
> Coleen
>
> On 11/27/2012 08:01 AM, Karen Kinnear wrote:
>> Hi Kris,
>>
>> I would concur. And there is also an explicit intention to not slow 
>> down JNI transitions by having the JVM do extra work. The
>> model is to have the JNI code restore a good state.
>>
>> Looks like we already have a flag that lets you know that you need to 
>> fix the jni code, so no need to add another way to do that.
>>
>> thanks,
>> Karen
>>
>> On Nov 26, 2012, at 10:57 PM, David Holmes wrote:
>>
>>> Hi Kris,
>>>
>>> I think historically hotspot assumes/requires JNI code to be well 
>>> behaved about these things. There have been some well known issues 
>>> with FPU state in the past. I'm not that familiar with MMX so can't 
>>> say whether it is reasonable for the VM to know when it has to do 
>>> this kind of cleanup.
>>>
>>> David
>>>
>>> On 27/11/2012 4:29 AM, Krystal Mo wrote:
>>>> Hi all,
>>>>
>>>> Xi Yang has reported a bug in HotSpot's interpreter that it doesn't
>>>> empty the FPU stack on return from JNI calls. His mail is included 
>>>> below.
>>>>
>>>> e.g. If a native function called via JNI is using MMX registers 
>>>> without
>>>> emptying the FPU stack before returning, then after returning to Java
>>>> the FPU stack will be in a bad state.
>>>>
>>>> The test case Xi gave is demonstrated here on JDK7u9, x86:
>>>> https://gist.github.com/4148771
>>>> Running the example with -XX:+VerifyFPU shows what's going on.
>>>>
>>>> This test case shows the bug affecting 32-bit x86 version of HotSpot's
>>>> interpreter.
>>>>
>>>> Not really familiar with how to file a bug on JBS yet, I'll file a bug
>>>> to track this after I learn how to do it.
>>>>
>>>> Regards,
>>>> Kris
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject: Fwd: Report a bug in HotSpot
>>>> Date: Tue, 27 Nov 2012 02:02:59 +0800
>>>> From: Krystal Mok <rednaxelafx at gmail.com>
>>>> To: Krystal Mo <krystal.mo at oracle.com>
>>>>
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Xi Yang <hiyangxi at gmail.com>
>>>> Date: Tue, Nov 20, 2012 at 1:44 PM
>>>> Subject: Report a bug in HotSpot
>>>> To: Krystal Mok <rednaxelafx at gmail.com>
>>>>
>>>>
>>>> Hi,
>>>>
>>>> It looks like HotSpot does not do "emms" after backing from JNI. Here
>>>> is the code to show the bug. Would you like to try the newest version?
>>>>
>>>>
>>>> Hello.java
>>>> class Hello {
>>>> private static native void abc();
>>>> public static void main(String[] args) {
>>>> System.out.println("I am main");
>>>> System.loadLibrary("Hello");
>>>> abc();
>>>> long a = 100;
>>>> double b = (double)a;
>>>> System.out.println("Double a is " + b);
>>>> }
>>>> }
>>>>
>>>> Hello.c
>>>> #include <jni.h>
>>>> #include <stdio.h>
>>>>
>>>> JNIEXPORT void JNICALL
>>>> Java_Hello_abc(JNIEnv *env, jclass cls)
>>>> {
>>>> printf("I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world\n");
>>>> unsigned int dummy;
>>>> asm volatile("movd %%mm0, %0\n":"=r"(dummy));
>>>> printf("dummy is %x\n", dummy);
>>>> }
>>>>
>>>>
>>>> gcc -m32 -shared ./Hello.c -o ./libHello.so
>>>>
>>>>
>>>> /opt/jdk1.7.0/bin/java -Djava.library.path=. Hello
>>>> I am main
>>>> I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world
>>>> dummy is 0
>>>> Double a is NaN
>>>>
>>>>
>>>> $ /opt/jdk1.7.0/bin/java -version
>>>> java version "1.7.0-ea"
>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b93)
>>>> Java HotSpot(TM) Server VM (build 18.0-b04, mixed mode)
>>>>
>>>>
>>>>
>