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

[David Holmes]

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