Protecting references from GC in JDI tests
Aditya Mandaleeka
adityam at microsoft.com
Mon Aug 17 19:07:22 UTC 2020
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()
More information about the serviceability-dev
mailing list