On 29.1.2015 16:59, shanliang wrote:
Jaroslav Bachorik wrote:
On 29.1.2015 14:43, shanliang wrote:
Jaroslav Bachorik wrote:
Please, review the following test change.
Issue : https://bugs.openjdk.java.net/browse/JDK-8071641
Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/
The test fails very intermittently with NPE. This seems to be caused
by a data race between Thread.getStatus() and
ThreadMXBean.getThreadInfo() - thread state is reported as BLOCKED but
the ThreadInfo still contains a stale information (lockname == null).
The solution would be re-retrieving the ThreadInfo until it reflects
the actual thread state.
-JB-
77 private static void waitForThreadState(Thread t, Thread.State
state) throws InterruptedException {
78 while (!t.isInterrupted() && t.getState() != state) {
79 Thread.sleep(3);
80 }
81 }
Better to throw an exception if t.isInterrupted()?
Not sure when will happen t.isInterrupted(), but the method
waitForThreadState tests it, so it is supposed to be possible to get it,
when it is true then the testing method might return with a thread state
different to the waited one.
Yes, it might get to an undefined state. But given that the thread
would get interrupted only when the harness is timing out the test
this discrepancy would not actually matter - the test would fail with
timeout anyway.
In this case it is useless to test t.isInterrupted() in waitForThreadState.
Probably it is. I will remove it before pushing then.
-JB-
Shanliang
-JB-
Shanliang
