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

[Tom Rodriguez]

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