RFR: 8257147: [TESTBUG] Set a larger default loop count for the VectorAPI jtreg tests

Xiaohong Gong xgong at openjdk.java.net
Thu Dec 10 10:21:35 UTC 2020


On Tue, 8 Dec 2020 20:25:18 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> The current default loop count of VectorAPI tests is too small (10 for load/store tests, 100 for arithmetic tests) to make the tests compiled with C2. This makes some potential issues not be reported as expected.
>> 
>> This patch fixes it by setting a larger default iteration.
>> 
>> The whole tests running time increases with this patch. Here is the results on two different types of machines:
>> 
>> Running with "`-conc:10`":
>>              Before     After
>> System A     5m30s      6m43s
>> System B     5m1s       6m31s
>> 
>> Running with "`-conc:1`":
>>              Before     After
>> System A     26m52s     45m6s
>> System B     30m3s      43m30s
>
> It's good to revisit this, but I am concerned about the increase in test execution time. I wonder if we can approach this a little differently.
> 
> First, I think we should switch off tiered compilation, `-XX:-TieredCompilation` (maybe reconsider later some limited form of execution with tiered compilation enabled).
> For such a configuration I observe, when using the current invocation count and looking at inline traces, far more lines with intrinsic `VectorSupport` methods.
> 
> Second, we could lower the compile threshold from 10000 e.g. `-XX:CompileThreshold=1000`. We can grep the inline trace and count the lines containing intrinsic `VectorSupport` methods.
> 
> Using both these approaches i think we can increase intrinsification without such a large increase in test execution time.
> 
> WDYT?

Hi @PaulSandoz , I tested the jtreg tests with these two options these days, and the results do not show better as expected. 

With `-XX:-TieredCompilation`, the tests can work well without increasing the loop count. However, I think it's not an optimal solution. First, with this flag, some issues that might only happen with tiered compilation might not be reported as expected (Currently we do have met a similar issue).  Second, a better way to add the option for the test is adding it to the test file (e.g. ` @run testng/othervm -XX:-TieredCompilation`).  However, this might override the same options people specified when running jtreg.

For `-XX:CompileThreshold=1000`, unfortunately it seems this flag doesn't have any effect that I still need to increase the loop count to make the tests effective.  Good news is that I found the flags `-XX:CompileThresholdScaling=0.1 -Xbatch` can work well even if I do not increase the loop count. However, this still increase the whole execution time a lot when running with `-conc:1`. Here is part of the comparison for the time:

Running with "-conc:10":
             Before     After
System A     5m21s      5m29s
System B     5m16s      6m7s

Running with "-conc:1":
             Before     After
System A     33m20s     62m14s
System B     36m17s     71m59s

So do you have tried these before? Or any better idea about this? Thanks!

Xiaohong Gong

-------------

PR: https://git.openjdk.java.net/jdk/pull/1621


More information about the hotspot-compiler-dev mailing list