-
Enhancement
-
Resolution: Unresolved
-
P4
-
19
If you launch a com/sun/jdi test with -Dmain.wrapper=Virtual, it will run the debuggee thread in a virtual thread. The manner in which it does this is a bit hard to follow, but roughly looks like this:
First in TestScaffold.parseArgs():
String mainWrapper = System.getProperty("main.wrapper");
if ("Virtual".equals(mainWrapper)) {
argInfo.targetAppCommandLine = TestScaffold.class.getName() + " " + mainWrapper + " ";
This puts "TestScaffold Virtual" in targetAppCommandLine. A bit later connect() is called, and regardless of whether or not the above was done, the rest of the command line is added:
argInfo.targetAppCommandLine += (args[i] + ' ');
args[] contains the real debuggee class name, plus any arguments to pass to it. So basically when using the wrapper the end result is prepending the command line with "TestScaffold Virtual", causing the main method of TestScaffold to be used rather than the main method of the debuggee itself. Then in TestScaffold.main():
String wrapper = args[0];
String className = args[1];
String[] classArgs = new String[args.length - 2];
This pulls the "Virtual" argument and the actual debuggee classname out of the args, and after this it will invoke <className>.main() on a virtual thread with the remaining args (classArgs).
A couple of things can be done to make this more readily understood by someone looking at the code. The first is to better comment it, and tie together what is done in parseArgs(), connect(), and main(). The second is to put main() in its own class, maybe DebuggeeWrapper. It's confusing to have it in TestScaffold, since TestScaffold is use as the superclass for the tests in com/sun/jdi, which have their own main() method. So the fact that it is actually used as a debuggee main() method is confusing.
Another area of improvement is argument handling by TestScaffold.main(). If the @run command contains extra arguments, or the test explicitly adds arguments itself, TestScaffold.main() does not handle them properly. This usually results in a ClassNotFoundException of the first added argument. I think this might be why a pretty large number of the com/sun/jid tests are failing (and are problem listed) when using the virtual thread wrapper. SeeJDK-8285422 and JDK-8285423.
First in TestScaffold.parseArgs():
String mainWrapper = System.getProperty("main.wrapper");
if ("Virtual".equals(mainWrapper)) {
argInfo.targetAppCommandLine = TestScaffold.class.getName() + " " + mainWrapper + " ";
This puts "TestScaffold Virtual" in targetAppCommandLine. A bit later connect() is called, and regardless of whether or not the above was done, the rest of the command line is added:
argInfo.targetAppCommandLine += (args[i] + ' ');
args[] contains the real debuggee class name, plus any arguments to pass to it. So basically when using the wrapper the end result is prepending the command line with "TestScaffold Virtual", causing the main method of TestScaffold to be used rather than the main method of the debuggee itself. Then in TestScaffold.main():
String wrapper = args[0];
String className = args[1];
String[] classArgs = new String[args.length - 2];
This pulls the "Virtual" argument and the actual debuggee classname out of the args, and after this it will invoke <className>.main() on a virtual thread with the remaining args (classArgs).
A couple of things can be done to make this more readily understood by someone looking at the code. The first is to better comment it, and tie together what is done in parseArgs(), connect(), and main(). The second is to put main() in its own class, maybe DebuggeeWrapper. It's confusing to have it in TestScaffold, since TestScaffold is use as the superclass for the tests in com/sun/jdi, which have their own main() method. So the fact that it is actually used as a debuggee main() method is confusing.
Another area of improvement is argument handling by TestScaffold.main(). If the @run command contains extra arguments, or the test explicitly adds arguments itself, TestScaffold.main() does not handle them properly. This usually results in a ClassNotFoundException of the first added argument. I think this might be why a pretty large number of the com/sun/jid tests are failing (and are problem listed) when using the virtual thread wrapper. See
- is blocked by
-
JDK-8303773 Replace "main.wrapper" with "test.thread.factory" property in test code
- Resolved
- relates to
-
JDK-8307778 com/sun/jdi/cds tests fail with jtreg's Virtual test thread factory
- Resolved
-
JDK-8285422 [LOOM] Some com/sun/jdi test are failing with the vthread wrapper
- Closed
-
JDK-8285423 [LOOM] com/sun/sde tests fail with the vthread wrapper due to using a custom classpath
- Closed