Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8289546

TestScaffold.java could use some improvements to virtual thread wrapper support.

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Unresolved
    • Icon: P4 P4
    • tbd
    • 19
    • core-svc

      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. See JDK-8285422 and JDK-8285423.

        There are no Sub-Tasks for this issue.

            lmesnik Leonid Mesnik
            cjplummer Chris Plummer
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: