Verification failure in SPECJVM2008.scimark.fft.small on Windows/32bit

[Volker Simonis]

Funny enough, my previous problem, which was caused by an uncleared FP
status register, only happend on 64-bit Windows and only with MSVC
2005 and 2008 while this problem happens only on 32-bit Windows and
with MSVC 2005 (the one we use for our builds) as well as with older
versions of MSVC (i.e. the one that is used for the official Java 7
buildss by SUN).

I finally found some documentation about the calling conventions on
Windows/x64 and it states: "A callee that modifies any of the fields
within FPCSR/MXCSR must restore them before returning to its caller.
Furthermore, a caller that has modified any of these fields must
restore them to their standard values before invoking a callee unless
by agreement the callee expects the modified values". I could however
only find this information for MSVC 2005 and 2008 (see
http://msdn.microsoft.com/en-us/library/ms235300(VS.80).aspx and
http://msdn.microsoft.com/en-us/library/ms235300.aspx) and I think you
use an older version for Windows builds, right?

Volker

On 10/30/08, Tom Rodriguez <Thomas.Rodriguez at sun.com> wrote:
> I haven't had a chance to investigate yet, but I wonder if this is related
> to the MXCSR issue you had mentioned previously?  AlwaysRestoreFPU doesn't
> deal with the MXCSR. -XX:+RestoreMXCSROnJNICalls does something similar
> though.
>
>  tom
>
>
>  On Oct 30, 2008, at 11:22 AM, Volker Simonis wrote:
>
>
> > Hi Tom,
> >
> > I ran the benchmark all day and I couldn't reproduce the problem
> > neither with -XX:UseSSE=0 nor with -XX:UseSSE=1 although I havent done
> > that many runs with -XX:UseSSE=1 like with -XX:UseSSE=0. It seems the
> > problem only shows up with -XX:UseSSE=2 or higher. I'll start a run
> > with "-XX:UseSSE=2 -XX:+CheckJNICalls" now and post the results
> > tomorrow. I have also found some other options which may be worth
> > trying them out: -XX:+AlwaysRestoreFPU and -XX:+VerifyFPU where the
> > last one is only available in the debug build.
> >
> > I've noticed that the tests uses a java.lang.ThreadLocal double array
> > to store and compute the values. May this be a problem perhaps?
> >
> > Did you had a chance to reproduce the problem?
> >
> > Regards,
> > Volker
> >
> > On 10/29/08, Tom Rodriguez <Thomas.Rodriguez at sun.com> wrote:
> >
> > > I haven't seen this before, though I pretty much never benchmark on
> windows.
> > > Is the use of -XX:+CITime required? have you tried debug builds?  Does
> it
> > > reproduce with -XX:UseSSE=0?  It might be interesting to run with
> > > -XX:+CheckJNICalls which will verify the various fp control words have
> the
> > > right value.  I'll see if I can reproduce it here.
> > >
> > > tom
> > >
> > >
> > > On Oct 29, 2008, at 11:55 AM, Volker Simonis wrote:
> > >
> > >
> > >
> > > > Hi,
> > > >
> > > > we have problems with SPECJVM2008 on Windows/x86 machines with at
> > > > least 4 cores and at least 4 benchmark threads. The benchmark
> > > > reproducible fails in the result verification of the sub-benchmark
> > > > scimark.fft.small (however in random places).
> > > >
> > > > We could reproduce the problem with JDK 6u7 and 6u10 as well as with
> > > > the latest JDK 7b38 however only for the 32-bit Windows versions.
> > > >
> > > > Because the problem occurs with both, C1 and C2 and because the
> > > > problem isn't reproducible neither with  -Xint, nor with the 64-bit
> > > > Windows or the Linux JDK, we think that this may be a problem in the
> > > > HotSpot runtime (perhaps a timing/concurrency problem with the
> > > > handling of 64-bit doubles in a 32-bit JDK on multi core machines?),
> > > > but this is only a wild guess.
> > > >
> > > > We also observed that all the files (JDK, test classes and result
> > > > files) had to be on the local host in order to reproduce the problem
> > > > and we had the impression that the benchmark fails more quickly on
> > > > Intel XEON, compared to AMD Opteron (we tested on the following
> > > > hardware: Intel (2x XEON (with HT), 3.4GHz, 8GB, MS Win Server 2003
> > > > Enterprise x64, SP1) and AMD (4x Opteron 270, 2.0GHz, 9GB, MS Win
> > > > Server 2003 Enterprise x64, SP1)).
> > > >
> > > > Has anybody else already observed this problem? Is this perhaps an
> > > > issue of SPECJVM2008.scimark.fft.small?
> > > >
> > > > Any comments would be highly appreciated!
> > > >
> > > > Regards,
> > > > Volker
> > > >
> > > > PS: JVM2008 is available from
> > > >
> > > http://www.spec.org/download.html
> > >
> > > >
> > > > PPS: here's the command line we used for the tests: java -server
> > > > -XX:+CITime -Djava.io.tmpdir=tmp -jar SPECjvm2008.jar -ikv -wt 30 -it
> > > > 60 -bt 4 --base scimark.fft.small scimark.fft.small scimark.fft.small
> > > > scimark.fft.small scimark.fft.small scimark.fft.small
> > > > scimark.fft.small scimark.fft.small scimark.fft.small
> > > > scimark.fft.small scimark.fft.small scimark.fft.small
> > > > scimark.fft.small scimark.fft.small scimark.fft.small
> > > > scimark.fft.small scimark.fft.small scimark.fft.small
> > > > scimark.fft.small scimark.fft.small
> > > >
> > > >
> > >
> > >
> > >
> >
>
>