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

[Jon Masamitsu]

Have you tried a different garbage collector?  With -server
you're likely using the UseParallelGC collector.  If you've
used -client, you're using the UseSerialGC collector (so
probably have already tried a different collector).  But just
to be sure if you run

java -server -XX:+PrintGCDetails -version

on your test machine you'l see something like this
for the UseParallelGC collector.

java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Server VM (build 1.6.0-b105, mixed mode)
Heap
  PSYoungGen      total 10752K, used 184K [0xf1400000, 0xf2000000, 
0xfc000000)
   eden space 9216K, 2% used [0xf1400000,0xf142e158,0xf1d00000)
   from space 1536K, 0% used [0xf1e80000,0xf1e80000,0xf2000000)
   to   space 1536K, 0% used [0xf1d00000,0xf1d00000,0xf1e80000)
  PSOldGen        total 24576K, used 0K [0xdbc00000, 0xdd400000, 0xf1400000)
   object space 24576K, 0% used [0xdbc00000,0xdbc00000,0xdd400000)
  PSPermGen       total 16384K, used 1465K [0xd7c00000, 0xd8c00000, 
0xdbc00000)
   object space 16384K, 8% used [0xd7c00000,0xd7d6e5c0,0xd8c00000)

where specifically, you'll see "PSYoungGen" in the output.

On 10/29/08 11:55, 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