This test launches a debuggee, which creates 11 instances of its main class, stores them in a static array of the main class, and then the debugger side iterates over all referrers to the main class instaces. Usually this is a pretty quick process and doesn't produce much in the way of output while walking the reference tree of referrers. However, with virtual threads the tree walking and output get unwieldy, and eventually it fails with:
IOException reading output of child java interpreter:Stream closed java.lang.IllegalThreadStateException at jdk.jdi/com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:76) at jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.name(ThreadReferenceImpl.java:197) at jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.toString(ThreadReferenceImpl.java:637) at java.base/java.lang.String.valueOf(String.java:4461) at ReferrersTest.showReferrers(ReferrersTest.java:438) at ReferrersTest.showReferrers(ReferrersTest.java:466) And ReferrersTest.showReferrers() has recursed about 200 levels deep. I'm not sure the order of these errors can be relied on. It looks like while walking the referrers tree, the test eventually stumbled upon a thread that had exited (but its Thread object was still alive), and this resulted in the test aborting. If I catch these exceptions, eventually the test times out while still working on referrers. Judging by some of the output, it appears that introducing the TestScaffold class as a referrer to the main debuggee class is the root cause of all these extra referrers. The test has a provision to cut off the recursion: // We have to stop going up a referrer chain in some cases Type rt = objRef.type(); if (rt instanceof ClassType) { ClassType ct = (ClassType)rt; String name = ct.name(); if (name.equals("sun.awt.SoftCache$ValueCell")) { return; } if (name.equals("java.lang.ref.Finalizer")) { return; } if (name.equals("java.lang.ref.SoftReference")) { return; } // oh oh, should really check for a subclass of ClassLoader :-) if (name.indexOf("ClassLoader") >= 0) { return; } // No doubt there are other reasons to stop ... } Adding TestScaffold to the list makes it so the referrer tree walking output is almost identical to what it is when not using virtual threads. Adding java.lang.reflect.Method instead does a slightly better job. Tested locally with and without the virtual thread wrapper. tier1 and tier5 svc testing tbd. ------------- Commit messages: - Do some additional pruning needed when run with a virtual thread Changes: https://git.openjdk.org/jdk/pull/14405/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14405&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309757 Stats: 5 lines in 2 files changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14405/head:pull/14405 PR: https://git.openjdk.org/jdk/pull/14405