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

Reply via email to