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

[Volker Simonis]

Just to bring this discussion to an end: we discovered that this
problem can be solved by using SP2 of Windows Server 2003 instead of
SP1. I'm still not sure that SP2 fixes a real Windows bug, but at
least the tests now runs as expected.

As I said before, I'm still not convinced that the problem is only in
the MS runtime, because I know from other problems we had that there
are really nasty interactions between the MS runtime, the MS VC
compiler and the machine code generated by the HotSpot when it comes
to floating point computations. So hopefully we won't see them again
with the next SP...

Best regards,
Volker

PS: after I reread the thread I must admit, that some details are
confusing, so just for the sake of completness: the problems mentioned
in this thread happend with a 32-bit JDK on a 64-bit Windows Server
2003 with SP1 running on a multicore CPU with support for at least
SSE2. They disappeared after the instalaltion of SP2.

On 11/11/08, Tom Rodriguez <Thomas.Rodriguez at sun.com> wrote:
> I tried reproducing this without luck though I couldn't find many machines
> with the right configuration. I'll try to find a machine that reproduces
> this.  Thanks for the report.
>
>  tom
>
>
>  On Nov 11, 2008, at 2:23 AM, Volker Simonis wrote:
>
>
> > Hi,
> >
> > unfortunately I had no success in finding a solution for this problem.
> > I have therefore opened a bug report (" Floating point failure in
> > 32-bit JDK 6/7 on multicore Windows with -XX:UseSSE=2"  with the
> > internal review ID 1389916).
> >
> > I think this is quite a serious problem and it would be nice, if
> > somebody could have a look on it.
> >
> > Thank you and best regards,
> > Volker
> >
> > PS: with the option "-XX:+TraceRuntimeCalls" I could see that the
> > benchmark calls "SharedRuntime::dsin(jdouble x)" quite often. The
> > problem is probably also not related to any kind of OnStackReplacement
> > or Deoptimization (I checked with "-XX:+TraceOnStackReplacement" and
> > "-XX:+TraceDeoptimization) because the offending methods are compiled
> > quite some time before the actual failure happens.
> >
> >
> >
> > On 10/31/08, Volker Simonis <volker.simonis at gmail.com> wrote:
> >
> > > 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
>
>