On Thu, 16 Mar 2023 21:02:09 GMT, Chris Plummer <[email protected]> wrote:
> The debuggee main method creates two threads and then starts them:
>
>
> public static void main(String[] args) {
> System.out.println("Howdy!");
> Thread t1 = TestScaffold.newThread(new InvokeHangTarg(), name1);
> Thread t2 = TestScaffold.newThread(new InvokeHangTarg(), name2);
>
> t1.start();
> t2.start();
> }
>
>
> These threads will hit breakpoints which the debugger handles and issues an
> invoke on the breakpoint thread. The threads run until they generate 100
> breakpoints. There is an issue when these two threads are virtual threads.
> Virtual threads are daemon threads. That means the JVM can exit while they
> are still running. The above main() method is not waiting for these two
> threads to exit, so main() exits immediately and the JVM starts the shutdown
> process. It first must wait for all non-daemon threads to exit, but there are
> none, so the JVM exits right away before the two threads are completed. The
> end result of this early exit is that sometimes the invoke done by the
> debugger never completes because the JVM has already issued a VMDeath event
> and the debuggee has been disconnected.
>
> When these two threads are platform threads, the JVM has to wait until they
> complete before it exits, so they will always complete. The fix for virtual
> threads is to do a join with t1 and t2. This forces the main() method to
> block until they have completed.
test/jdk/com/sun/jdi/InvokeHangTest.java line 223:
> 221: mainThread = bpe.thread();
> 222: EventRequestManager erm = vm().eventRequestManager();
> 223: final Thread mainTestThread = Thread.currentThread();
This local variable was conflicting with an instance field of the same name.
See line 135. I ran into issues when I added some debugging code to this method
that referenced the other `mainThread`, so I did a rename.
-------------
PR: https://git.openjdk.org/jdk/pull/13068