RFR: 8309697: [TESTBUG] Remove "@requires vm.flagless" from jtreg vectorization tests [v2]

[Pengfei Li]

On Thu, 3 Aug 2023 19:27:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Pengfei Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-work correctness check to allow "-Xbatch"
>
> Thank you for addressing the test issue.
> 
> About your change to allow -Xbatch. Let me clarify, if you exclude `-Xcomp` mode (which I agree with) by checking  `UseInterpreter` flag for `true`, then a method could be always executed in Interpeter to get reference result (even with -XX:CompileThreshold=100)  by calling method once first (we do that in other tests).
> You don't need to limit test to `Tiered` mode when Interpreter is available and original test code should work.
> 
>>For -Xbatch we need check BackgroundCompilation. As we lock the compilation before running the test method in the interpreter to get reference result, the VM will hang if both background compilation is disabled and the compilation is locked by WhiteBox.
> 
> You don't need to call `WB.lockCompilation()` if you exclude `-Xcomp` mode. There will be no compilation requests for called method when you call the method first time because compilation threshold will not be reached - it is guarantee that method will be executed in Interpreter. And you have the assert to verify that.
> 
> Note, this work with and without BackgroundCompilation enabled. If you called a method once it will be executed in Interpreter if `-Xcomp` is excluded.

Hi @vnkozlov ,

Thanks for your reply. But it still has problems.

> About your change to allow -Xbatch. Let me clarify, if you exclude -Xcomp mode (which I agree with) by checking UseInterpreter flag for true, then a method could be always executed in Interpeter to get reference result (even with -XX:CompileThreshold=100) by calling method once first (we do that in other tests).

> You don't need to call WB.lockCompilation() if you exclude -Xcomp mode. There will be no compilation requests for called method when you call the method first time because compilation threshold will not be reached - it is guarantee that method will be executed in Interpreter. And you have the assert to verify that.

These tests are a bit different because we test loops. If the loop iteration count reaches some threshold, the loop will be *OSR compiled* even test method is called only once. I just did an experiment according to your suggestion. After removing `WB.lockCompilation()` and updating loop iteration count to 100,000, I got assertion failure that tells me the test method is NOT running in interpreter.


STDERR:
java.lang.AssertionError
	at compiler.vectorization.runner.VectorizationTestRunner.runTestOnMethod(VectorizationTestRunner.java:131)
	at compiler.vectorization.runner.VectorizationTestRunner.run(VectorizationTestRunner.java:73)
	at compiler.vectorization.runner.VectorizationTestRunner.main(VectorizationTestRunner.java:215)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1570)


A solution to this may be adding one more check of `CICompileOSR` is OFF if we still want to use interpreted execution for the reference result.

Now the question is, which verification approach do you think is better? "C2 vs. interpreted" or "C2 vs. C1"?

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

PR Comment: https://git.openjdk.org/jdk/pull/15011#issuecomment-1665082893