FYI. Staffan has a fix in hotspot for JDK-8016304 the ThreadMXBean issue
[1].
Thanks
Mandy
[1]
http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-June/010194.html
On 6/17/2013 6:21 AM, Daniel Fuchs wrote:
Hi,
Please find below a webrev for fixing
8014218: test/java/util/logging/DrainFindDeadlockTest.java failing
intermittently
<http://cr.openjdk.java.net/~dfuchs/JDK-8014218/webrev.00/>
Without the fix - it's quite easy to make the test fail - especially
if you copy paste the @run line a few times.
This test is supposed to detect a deadlock in Logger initialization,
but it detects too many false positive.
An analysis of stack traces that the test dumps when it fails shows
that there is actually no deadlock, since one of the two supposed
deadlock threads is RUNNABLE.
However - this - I think - indicates a bug in
ThreadMXBean.findDeadlockedThreads().
I have rewritten the test to sanitize the results before
and after calling ThreadMXBean.findDeadlockedThreads().
Namely - the test will call ThreadMXBean.findDeadlockedThreads()
only if the two threads it monitors are simultaneously blocked
(obtained by examining ThreadMXBean.getThreadInfo(long[])), and
will verify that all threads found in deadlock by
ThreadMXBean.findDeadlockedThreads() are indeed blocked.
Now - I'm not sure whether this is a good thing or not:
pros: it makes it possible to run this test again - and have a greater
confidence that if it fails it's because of a genuine deadlock,
which is desirable.
cons: it 'hides' a possible bug in ThreadMXBean.findDeadlockedThreads()
as it appears the test was testing
ThreadMXBean.findDeadlockedThreads() more than (or as much
as) it was testing the Logger implementation.
Does it make sense to push this fix and log a bug against ThreadMXBean?
Or should I instead plan to add this test to the problem list
(and re-qualify the bug as an issue in ThreadMXBean)?
guidance appreciated!
best regards,
-- daniel
