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

[Volker Simonis]

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