Protecting references from GC in JDI tests

[Daniel D. Daugherty]

Aditya,

I think you've found the right alias...

A similar observation was made here:

http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030635.html

It looks like that conversation didn't go beyond Egor's original message
and Chris P's reply.

My recommendation would be to only use ObjectReference.DisableCollection()
when you have observed a specific failure for a specific object in a test.
I would not apply that function generally. However, Chris P. or another
member of the Serviceability team may have other guidance...

Dan


On 8/17/20 3:07 PM, Aditya Mandaleeka wrote:
> 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()
>