JdbMethodExitTest.java tries to determine the jdb threadID for the "main" thread, and then later use it in jdb commands that require a threadID. It does this by first having the debuggee execute the following:

        System.out.println("threadid="+Thread.currentThread().getId());

And then later on the test parses the threadID from this output. The problem is that the id returned by getId() has no relation to threadIDs used by jdb, which are actually JDWP ObjectIDs. In the past this has worked due to some dumb luck. getID() always returns 1 for the main thread, which is always the thread we are executing in. Coincidentally the JDWP ObjectID for the main Thread object is also always 1 because this is the first ObjectID that the debug agent ever needs to create. However, when the debuggee main thread is a virtual thread, neither getId() nor JDWP assign 1 to the threadID, and in fact both will end up with very different values for the threadID. The end result is errors from jdb for using an invalid threadID.

The correct threadID can be obtained by executing the jdb "threads" command and parsing it from a line that looks like the following:

   (java.lang.VirtualThread)694 main running (at breakpoint)

Note this test will also fail due to JDK-8309334 and JDK-8309397, which should be fixed first.