Techniques for debugging threading issues with Virtual Threads

[Alex Otenko]

By the way, deadlocks specifically should be discoverable automatically
without a thread dump.

On Wed, 20 Nov 2024, 07:10 Dr Heinz M. Kabutz, <heinz at javaspecialists.eu>
wrote:

> With platform threads, we have had good techniques for finding threading
> issues. For example, a thread dump would reveal deadlocks, livelocks and
> contention.
>
> However, with virtual threads, most of these techniques won't work
> anymore. For example, here is a SimpleDeadlock:
>
> import java.util.concurrent.locks.*;
>
> public class SimpleDeadlock {
>      public static void main(String... args) throws InterruptedException {
>          var monitor1 = new Object();
>          var monitor2 = new Object();
>          Thread.startVirtualThread(() -> {
>              synchronized (monitor1) {
>                  LockSupport.parkNanos(10_000_000);
>                  synchronized (monitor2) {
>                      System.out.println("Got both locks");
>                  }
>              }
>          });
>          Thread.startVirtualThread(() -> {
>              synchronized (monitor2) {
>                  LockSupport.parkNanos(10_000_000);
>                  synchronized (monitor1) {
>                      System.out.println("Got both locks");
>                  }
>              }
>          }).join();
>      }
> }
>
> If we run this with Java 21-23 and -Djdk.trackAllThreads=false, the
> carrier thread indicate that they are carrying some virtual threads, but
> these do not appear in the full dump. In Java 24+24, the virtual threads
> are parked instead of pinned, and thus they vanish completely from the
> thread dumps.
>
> Is there any project or workgroup where debugging of virtual threads is
> being looked at?
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java™ Specialists' Newsletter" - www.javaspecialists.eu
> Java Champion - www.javachampions.org
> JavaOne Rock Star Speaker
> Tel: +30 69 75 595 262
> Skype: kabutz
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20241120/83783f04/attachment.htm>