[12] RFR(S) 8207153: Some intrinsic tests take long time to run

[Vladimir Kozlov]

 > Sorry, I wasn’t clear: What I’m wondering is if we should *require* the test to be scheduled on a 
machine where the intrinsic is available, so that it actually gets tested. Right now it’s a lottery 
if the test ends up executing on a machine with that functionality, which could mean that the test 
never or very rarely actually does end up running. However, there’s probably a risk that doing this 
would make some machines bottlenecks for testing, so may not be a good idea in the end…

Yes, it would be nice! In my mach5 testing of these changes Base64 test (which uses avx512) where 
never run on avx512 machine and was skipped in 10 runs :(

I would actually hope that at least one our testing tier is run on avx512 machine. avx512 is used in 
vectorization and it would be nice to run all tests instead of only one which use avx512 in 
intrinsics. And we have related concern about 8207746: C2: Lucene crashes on AVX512.

We need to be smart about using limited resources we have. I agree.

Thanks,
Vladimir

On 8/13/18 11:34 AM, Mikael Vidstedt wrote:
> 
> 
>> On Aug 13, 2018, at 9:57 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> On 8/13/18 9:44 AM, Mikael Vidstedt wrote:
>>> Two questions:
>>> 1. What happens if somebody decides to rename to Java method(s), but forgets to update the test?
>>
>> WB.isIntrinsicAvailable() if intrinsic for old method is not available - there will be no ID for it and we will hit assert:
>>
>> http://hg.openjdk.java.net/jdk/jdk/file/9fe4fc157f4e/src/hotspot/share/opto/c2compiler.cpp#l164
>>
>>> 2. Can/should we force this test to only run on machines where the underlying instructions are in fact available?
>>
>> WB.isIntrinsicAvailable() checks flag:
>>
>> http://hg.openjdk.java.net/jdk/jdk/file/9fe4fc157f4e/src/hotspot/share/classfile/vmSymbols.cpp#l712
>>
>> and flag is set only when HW instructions are available:
>>
>> http://hg.openjdk.java.net/jdk/jdk/file/9fe4fc157f4e/src/hotspot/cpu/x86/vm_version_x86.cpp#l755
> 
> Sorry, I wasn’t clear: What I’m wondering is if we should *require* the test to be scheduled on a machine where the intrinsic is available, so that it actually gets tested. Right now it’s a lottery if the test ends up executing on a machine with that functionality, which could mean that the test never or very rarely actually does end up running. However, there’s probably a risk that doing this would make some machines bottlenecks for testing, so may not be a good idea in the end…
> 
> Cheers,
> Mikael
> 
>>
>> Vladimir
>>
>>> Cheers,
>>> Mikael
>>>> On Aug 10, 2018, at 5:05 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>>
>>>> http://cr.openjdk.java.net/~kvn/8207153/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8207153
>>>>
>>>> Use WhitBox API isIntrinsicAvailable() to guard execution of TestAESMain.java and TestBase64.java.
>>>> Also reduced number of loop iterations from 1M to 100K. Tests run with -Xbatch - compilation is guarantee with smaller number. And I checked results with +LogCompilation.
>>>>
>>>> Tested by running these 2 tests on X86 and SPARC.
>>>> And run locally using intrinsics flag to switch them off to confirm that new guard in tests works.
>>>>
>>>> -- 
>>>> Thanks,
>>>> Vladimir
>