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

[Vladimir Ivanov]

>>> 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.

Best regards,
Vladimir Ivanov