Hi serviceability-dev, I hope this is the right list for this topic, but feel free to redirect if not...
It appears that there are jtreg tests that exercise JDI functionality without protecting target objects from being GC'd. An example of this is com/sun/jdi/VarargsTest.java, where references are acquired (with mirrorOf) and then used as args in invokeMethod. I haven't looked into all the other JDI tests to see if there are others with the same issue. This issue was exposed in our test runs with Shenandoah GC in aggressive heuristics mode (which does back to back GCs), but of course it can also be reproduced by inducing a GC in the target VM explicitly before the invoke. While this is unlikely to occur in practice when not using a special GC mode, it seems to me that the tests should not be relying on the fact that a GC _probably_ won't occur, and instead explicitly disable collection on the objects that are going to be used. After all, it is specified in the docs that ObjectReference values returned by JDI may be collected at any time the target VM is running unless disableCollection() is called on them [0], so the test code is implicitly relying on lifetime guarantees that are not provided. I think the test(s) could be improved by calling disableCollection on any references in the target VM prior to using them. There is of course a chance that an object could be GC'd before the disableCollection call, but I inspected the code for this case and it appears the JDWP error code gets converted into an ObjectCollectedException surfaced to user code which we could handle in the test (and perhaps retry the operation a few times before giving up). Is my understanding correct here? What are your thoughts on this? Is there interest in these tests being fixed in this way? Thanks, Aditya [0]: https://docs.oracle.com/en/java/javase/11/docs/api/jdk.jdi/com/sun/jdi/ObjectReference.html#disableCollection()
