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()
