A number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests don't take this into account, and can hence get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is needed (but also note that the object could have been collected by the time we call `disableCollection()`).
In addition, `SDEDebuggee::executeTestMethods()` creates class loaders, which shortly after dies (and potentially gets collected). This creates problems on the debugger side, since code locations in this (now potentially unloaded class/method) gets invalidated. We must ensure that these class loaders stay alive to avoid these problems. Normally, these problems are fairly hard to provoke, since you have to be unlucky and get the timing of a GC just right. However, it's fairly easy to provoke by forcing GC cycles to happen all the time (e.g. using ZGC with -XX:ZCollectionInterval=0.01) and/or inserting `Thread.sleep()` calls right after calls to `newInstance()'. This patch fixes all instances of this problem that I managed to find. Testing: All `vmTestbase/nsk/jdi/` tests now pass, even when using the above described measures to try to provoke the problem. ------------- Commit messages: - 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException Changes: https://git.openjdk.java.net/jdk/pull/1348/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1348&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255987 Stats: 168 lines in 8 files changed: 137 ins; 0 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/1348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1348/head:pull/1348 PR: https://git.openjdk.java.net/jdk/pull/1348
