[12] RFR (T): 8146090: java/lang/ref/ReachabilityFenceTest.java fails with -XX:+DeoptimizeALot

[Vladimir Ivanov]

Thanks for review, David & Igor!

Best regards,
Vladimir Ivanov

On 04/12/2018 17:15, David Holmes wrote:
> On 5/12/2018 11:12 am, Vladimir Ivanov wrote:
>>
>>>>> I just added a query to the bug report. I can't tell what other 
>>>>> flags get tested in same run that uses DeoptimizeALot. Is it better 
>>>>> to exclude the test from all such runs, or to force DeoptimizeALot 
>>>>> off in the @run lines?
>>>>
>>>> The flag is used in hs-comp testing (tier7-8) and it turns on 
>>>> heavyweight stress mode. The actual flag combinations being tested are:
>>>>
>>>>    -ea -esa -XX:CompileThreshold=100 -server 
>>>> -XX:[+-]TieredCompilation [-Xcomp] -XX:+DeoptimizeALot
>>>>
>>>> I'm in favor of excluding the test, since I don't see much value in 
>>>> running the test with the flag explicitly disabled: it duplicates 
>>>> testing in other configurations.
>>>
>>> Which other tier config would this duplicate? As long as we are 
>>> stress testing the reachability fence then I'm okay with this, but I 
>>> want to be sure we are stress testing it. Ensuring reachability 
>>> fences are kept in place and maintain object liveness is exactly what 
>>> we need to check under heavy compilation etc.
>>
>> It's hard to precisely enumerate all the configurations where it is 
>> executed, but from what I'm seeing the configs:
>>
>>    * -XX:+DeoptimizeALot is only part of compiler testing
>>
>>    * jdk jtreg tests (part of jtregNonCompiler group) are also 
>> executed in tier4 & tier6;
>>
>>  From what I'm seeing -Xcomp mode is covered:
>>
>>     -ea -esa -XX:CompileThreshold=100 -server 
>> -XX:[+-]TieredCompilation -Xcomp
>>
>>
>> I don't immediately see whether it's tested in non-Xcomp with low 
>> compilation threshold:
>>
>>    -ea -esa -XX:CompileThreshold=100 -server -XX:[+-]TieredCompilation
>>
>> The test is executed in mixed mode (with default threshold) in 
>> non-compiler tiers + promotion testing.
>>
>>
>> My point was more about -XX:+DeoptimizeALot being a dedicated stress 
>> mode which is used _in addition_ to other testing modes. Considering 
>> the test doesn't work with it, I'm in favor of excluding it (as was 
>> proposed) than running it with -XX:-DeoptimizeALot.
> 
> Thanks for all the info. I just wanted to be sure that excluding the run 
> that sets +DeoptimizeALot didn't also mean we were excluding all/most of 
> the stress testing for this test.
> 
> Looks good to go.
> 
> Thanks,
> David
> 
> 
>> Best regards,
>> Vladimir Ivanov