Re: yet another Java oddity

[Daniel J Sebald]

On 02/08/2013 03:54 PM, Mike Miller wrote:
> On Thu, Feb 7, 2013 at 1:27 PM, Daniel J Sebald wrote:
> > On 02/07/2013 09:32 AM, John W. Eaton wrote:
> > > That's odd. Does the JVM set some FPU flags that are different from the
> > > default that could affect the values that std::pow computes?
> >
> >
> > I was just about to email to propose that could be happening.  Perhaps there
> > is a bug in Java that isn't fully restoring the state of the CPU registers
> > when it returns.  Could be a machine specific problem.
>
> tl;dr - Yes, Java does in fact modify the FPU control word which ends
> up reducing the floating point precision that Octave normally
> calculates with. I think the right way to handle this is to restore
> the FPU flags so that values are computed consistently whether Java is
> loaded or not. I will work on a changeset that restores the expected
> precision on i386.

As Jordi said, nice detective work there.


> Details:
>
> > From some searching and looking through the openjdk source, I gather
> that the Java spec requires all floating point operations to be either
> single or double, even intermediate results [1]. What this translates
> to in the openjdk implementation (and probably others) is that they
> disable the long double format at the hardware level in the x87 FPU
> control word; this does not apply to x86_64. This is almost certainly
> the source of all of the differences I have been observing, I will
> soon have standalone C examples to confirm each of the effects.

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.


> I made a quick POC hack to Octave to restore the default FPU state
> after loading the JVM, which works, but it apparently is reset to
> Java's desired state with every call into Java, including the readline
> event hook installed in ov-java.cc. This means we will need to restore
> the FPU state after every Java class instantiation, method call, etc.

Sounds good, but can this be classified as a Java bug?  If so, perhaps 
this should be reported and fixed within openjdk.

Dan



> The reason I was not seeing test failures with 'make check' is because
> ATLAS was installed and I believe it was restoring the FPU state after
> Java messed with it. When I ran tests individually in the interpreter,
> that allowed the readline event hook to call Java, which screwed up
> the FPU again after returning to the prompt.
>
> This is very specific to i386; some work may still need to be done on
> other architectures.
>
> [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.2.4

--

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com