Report a bug in HotSpot

[Karen Kinnear]

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