Re: yet another Java oddity

[Mike Miller]

On Fri, Feb 8, 2013 at 5:33 PM, Daniel J Sebald wrote:
> On 02/08/2013 04:12 PM, Daniel J Sebald wrote:
>> Yeah, I suppose it's aiming to be device independent, so all one or all
>> the other, and no worries about the various combinations of address
>> length and register length.
>
>
> Actually, it's a mix of 32 bit and 64 bit with promotion rules.  I've tried
> to locate the source code, but openjdk is a pretty big project with multiple
> repositories.  I'm not sure if it would be in the development kit or the
> virtual machine either.

Yeah, tell me about it. The parts I looked at I can point you to, the
embedded math library fdlibm:

http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/f4bdaaa86ea8/src/share/native/java/lang/fdlibm/src/

and the Hotspot VM, which is where I think the bulk of the VM spec is
implemented:

http://hg.openjdk.java.net/jdk6/jdk6/hotspot/
http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/cd74fab0a5e3/src/cpu/x86/vm/

> I'm guessing that Java is running in the same thread, correct? Otherwise, it
> seems like the OS might handle restoring the state.

Java is running in the same thread and also in separate threads that
are kicked off in the background when the JVM is loaded.

Yes, the FPU state is thread-local so we only have to worry about the
entry into and exit from Java code in the main interpreter thread. And
it definitely is being set with every entry into Java.

> Well, use your judgment as to what level of software should be concerned
> about this.

I still think it's best if we handle this ourselves. Even if we were
able to get openjdk to accept this as a bug and fix it, we'd still
have to handle current implementations, and other JVMs. In fact, the
approach I'm proposing is what openjdk does for calls to native code.
In the hotspot code there is even an optional warning you can enable
for when a JNI routine changes the FPU state and doesn't restore it
when returning control to the JVM.

Thanks for the feedback.

-- 
mike