Daniel,
The test does 2 steps of verifications, the new check is useful for the
first step, and the trace in the bug showed that the test failed on the
first step.
Yes the check might not work for the second step, I added the new code
for the second step to check the tested thread state and hope to have
useful info if the test failed on the second step.
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8050115/02/
Thanks,
Shanliang
Daniel Fuchs wrote:
On 9/17/14 10:55 AM, shanliang wrote:
David Holmes wrote:
On 17/09/2014 7:01 AM, shanliang wrote:
David Holmes wrote:
Hi Shanliang,
On 16/09/2014 7:12 PM, shanliang wrote:
Hi,
Please review the following fix:
I don't see any functional change. You seem to have replaced a
built-in timeout with the externally applied test harness timeout.
Yes no functional change here, we thought that the test needed more
time
to wait a change if a testing VM or machine was really slow, the test
harness timeout was the maximum time we could give the test.
Do we have confidence that the harness timeout is sufficient to handle
the intermittent failures?
Really a good question :)
Here is new version:
http://cr.openjdk.java.net/~sjiang/JDK-8050115/01/
I added a deadlocked check in every 1 second, hope to get more info in
case of failure.
The following comment seems to imply that this check is not
very useful:
112 // This won't show up as a deadlock in CTRL-\ or in
113 // ThreadMXBean.findDeadlockedThreads(), because they
don't
114 // see that thread A is waiting for thread B
(B.join()), and
115 // thread B is waiting for a lock held by thread A
best regards,
-- daniel
I changed also the sleep time to 100ms, 10ms seems too short as Daniel
pointed out.
Thanks,
Shanliang
Thanks,
David
Style nit: add a space after 'while' -> while (cond) {
OK, I will do it before pushing.
Thanks,
Shanliang
David
-----
bug: https://bugs.openjdk.java.net/browse/JDK-8050115
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8050115/00/
Thanks,
Shanliang
