On Fri, 20 Nov 2020 13:23:28 GMT, Per Liden <pli...@openjdk.org> wrote:
> 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1348
