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

[Christian Thalinger]

+   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