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
