On Thu, 30 Jun 2022 16:27:12 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> The @run suggestion doesn't work. There are two issues. First, it does not >> trigger jtreg to use TestScaffold.main(), which is what normally happens >> when you use TEST_VM_OPTS="-Dmain.wrapper=Virtual". So the end result is >> that the test is run with a platform thread. >> >> The other issue is that if the test run is done with >> TEST_VM_OPTS="-Dmain.wrapper=Virtual", then TestScaffold.main() cannot >> handle any arguments added to the @run other than the main class name. You >> end up with CNFE for the first argument that appears after >> "SuspendAfterDeath". >> >> The above issues aside, I still don't understand why we would want to do any >> virtual thread testing with com/sun/jdi tests when not using >> TEST_VM_OPTS="-Dmain.wrapper=Virtual". It's not how we've tested JDI support >> for virtual thread in the past. We've always relied on explicit virtual >> thread test runs using TEST_VM_OPTS="-Dmain.wrapper=Virtual". Same is true >> of the nsk jdi, jdb, and jdwp tests. If you really want this test handled >> differently because it was written to test a specific bug, then it probably >> does not belong in com/sun/jdi, which means it can't rely on TestScaffold. >> >> One other thing is that you don't really need -Dmain.wrapper=Virtual to make >> this test do the testing on a virtual thread. It can just be the default >> mode like you used to have when you first wrote it. However, I ran into >> problems with that when also using TEST_VM_OPTS="-Dmain.wrapper=Virtual" >> due to conflicts in argument setup between the test and TestScaffold. >> However, with the changes now in parseArgs() to check test.enable.preview, >> it might not be necessary for the test itself to add --enable-preview, so >> maybe that conflict will go away. But I still don't think this is the >> approach we should take (see my previous paragraph). > > The testing in OpenJDK does not run these tests with -Dmain.wrapper=Virtual > so this is why this test is not testing the scenario that this bug is about. > We can make it work and have it run twice, or we can rename it to something > like "SuspendVirtualThreadAfterDeath" and drop the testing with a platform > thread. In time I expect there will be more tests in the jdk_jdi test group > that exercise virtual threads. I've updated the test to always run in both virtual thread and platform thread mode. The test itself does not care about the `-Dmain.wrapper=Virtual` setting and ignores it. TestScaffold does care and will run the main test thread as a virtual thread if `-Dmain.wrapper=Virtual` is used, but the test itself will spawn a virtual thread or platform thread independent of the wrapper setting. ------------- PR: https://git.openjdk.org/jdk19/pull/88
