Hi Peter,
On 2015-12-04 13:35, Peter Levart wrote:
On 12/04/2015 08:16 AM, Per Liden wrote:
test/java/lang/ref/PhantomReferentClearing.java:
85 // Delete root -> O1, collect, verify P1 notified, P2 not
notified.
86 O1 = null;
87 System.gc();
88 if (Q1.remove(ENQUEUE_TIMEOUT) == null) {
89 throw new RuntimeException("P1 not notified by O1
deletion");
90 } else if (Q2.remove(ENQUEUE_TIMEOUT) != null) {
91 throw new RuntimeException("P2 notified by O1
deletion.");
92 }
93
94 // Delete root -> O2, collect. P2 should be notified.
95 O2 = null;
96 System.gc();
97 if (Q2.remove(ENQUEUE_TIMEOUT) == null) {
98 throw new RuntimeException("P2 not notified by O2
deletion");
99 }
The calls to System.gc() isn't guaranteed to do what the test expects
here. As you know, System.gc(), might not actually do anything,
depending on which collector is used and the current circumstances (GC
locker held, a concurrent GC is already in process, etc). To make the
test robust I'd suggest you call System.gc() and check the queue in a
loop, and fail after some reasonable amount of time/iterations.
Whether you poll the queue for some time T or you remove from queue with
timeout of T, it doesn't matter. The Reference(s) are enqueued by a
ReferenceHandler thread and the thread waiting in remove() will get
notified when a reference gets enqueued...
I think you maybe missed my point. There's no guarantee that a call to
System.gc() will cause reference processing to happen at all, and if it
happens there's no guarantee that it will discover P1/P2 here. In this
specific test it's very likely to happen, but that's a different story.
I still don't think this test should rely on a behavior that isn't
guaranteed by the spec.
cheers,
/Per
Regards, Peter
cheers,
/Per
http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/
Testing:
jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK)
