RFR [8038333] java/lang/ref/EarlyTimeout.java failed (original) (raw)
Ivan Gerasimov ivan.gerasimov at oracle.com
Wed Mar 26 20🔞10 UTC 2014
- Previous message: RFR [8038333] java/lang/ref/EarlyTimeout.java failed
- Next message: RFR [8038333] java/lang/ref/EarlyTimeout.java failed
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Thank you Mandy!
Are you able to reproduce the test failure?
Yes, I could easily reproduce the failure when I reduced the timeout to 10 ms. With the timeout reduced, the test fails every third time on my machine.
I think the test verifies that only one thread gets the reference is a good test. But if none of the threads could get the reference, it should not cause the failure of the test. It only means that during this particular run we could not have tested what we needed. We could retry, but I'm not sure it's worth complicating the test. It's easier to ignore the failure, taking into account that it happens rarely.
I think the race is due to the threads get to call queue.remove as soon as both threads decrement the count of the latch that can be well before the reference is enqueued. The problem is that we have no way to block the main thread until there is a reference in the queue. I improved the situation a bit, having moved the await() after the call of gc().
It'd be good to add additional information in the test to help diagnosing test failure. I added reporting to stderr about being unable to remove a reference from the queue. I believe we shouldn't treat it as an error, and should simply ignore it.
Would you please have a look at the updated webrev: http://cr.openjdk.java.net/~igerasim/8038333/1/webrev/
Sincerely yours, Ivan
- Previous message: RFR [8038333] java/lang/ref/EarlyTimeout.java failed
- Next message: RFR [8038333] java/lang/ref/EarlyTimeout.java failed
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]