RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java fails intermittently

[Martin Buchholz]

Tests that sleep can almost always be better written some other way.
In this case, I would prefer busy-waiting with timeout until the expected
condition becomes true.

Here's some code from jsr166 tck tests:

    /**
     * Spin-waits until sync.isQueued(t) becomes true.
     */
    void waitForQueuedThread(AbstractQueuedSynchronizer sync, Thread t) {
        long startTime = System.nanoTime();
        while (!sync.isQueued(t)) {
            if (millisElapsedSince(startTime) > LONG_DELAY_MS)
                throw new AssertionFailedError("timed out");
            Thread.yield();
        }
        assertTrue(t.isAlive());
    }


On Thu, Apr 30, 2015 at 7:25 AM, Jaroslav Bachorik <
jaroslav.bachorik at oracle.com> wrote:

> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8078143
> Webrev: http://cr.openjdk.java.net/~jbachorik/8078143/webrev.00
>
> The test fails intermittently due to inconsistent reporting of the live
> threads number.It is related to
> https://bugs.openjdk.java.net/browse/JDK-8021335 (or, better said, caused
> by) - certain performance counters used for the thread accounting are being
> updated under a mutex but are read without it - and it can lead to stale
> data being reported. More details are available in the linked issue and
> discussion.
>
> Because of this it is not enough to join() a terminating thread to make
> sure the numbers would be correct. Luckily enough, it seems to be
> sufficient to wait for a short time before actually accessing the counters
> to be able to get a consistent view. In this fix I opted for a ridiculously
> huge interval of 500ms just to be sure.
>
> Thanks,
>
> -JB-
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150430/ec24aee7/attachment.html>