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

[Tom Rodriguez]

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