Protecting references from GC in JDI tests

[Roger Riggs]

Hi,

You may also find useful java.lang.ref.Reference.reachabilityFence(obj [1] .
It is designed to prevent the compiler from optimizing away a reference.
It keeps the object referenced up to that point.

[1] 
https://download.java.net/java/GA/jdk14/docs/api/java.base/java/lang/ref/Reference.html#reachabilityFence(java.lang.Object)

Regards, Roger


On 8/17/20 3:21 PM, Daniel D. Daugherty wrote:
> 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()
>>
>