RFR (S) 8037226: compiler/7196199/Test7196199.java fails on 32-bit linux with MaxVectorSize > 16

[Vladimir Kozlov]

Thank you, Christian

I added:

     // Verify that OS save/restore all bits of AVX registers
     // during signal processing.

Thanks,
Vladimir

On 3/14/14 4:48 PM, Christian Thalinger wrote:
> +   static bool os_supports_avx_vectors() {
> +     if (!supports_avx()) {
> +       return false;
> +     }
>
> A small comment here would be nice.  Maybe:
>
> +     // Verify that OS save/restore AVX registers.
>
> +     int nreg = 2 LP64_ONLY(+2);
> +     for (int i = 0; i < 8 * nreg; i++) { // 32 bytes 4 ymm registers
> +       if (_cpuid_info.ymm_save[i] != ymm_test_value()) {
> +         return false;
> +       }
> +     }
> +     return true;
> +   }
>
> Otherwise this looks good.
>
> On Mar 14, 2014, at 4:01 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> I updated changes to include more ymm registers to test and print them in debug VM.
>>
>> http://cr.openjdk.java.net/~kvn/8037226/webrev.01/
>>
>> Thanks,
>> Vladimir
>>
>> On 3/13/14 11:11 PM, Vladimir Kozlov wrote:
>>> WARNING: it is ugly but I don't know an other way to fix the problem and
>>> keep wide AVX vectors.
>>>
>>> Some operating systems (or VMs) does not restore upper 128 bit of AVX
>>> registers YMM after signal processing. About year ago Mac OS had this
>>> problem (8003878). And now we found 32-bit Ubuntu (Linux 3.8.0-29) which
>>> has the same problem.
>>>
>>> Instead of reducing vectorization to 16 bytes (XMM registers) I added
>>> code which verifies YMM state after signal processing and set limit on
>>> vector's size. The code is part of cpuid info code which JVM executes
>>> during startup.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8037226
>>> http://cr.openjdk.java.net/~kvn/8037226/webrev/
>>>
>>> Tested on failing machines.
>>>
>>> thanks,
>>> Vladimir
>