jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently

[shanliang]

If it is not possible to prevent JVM to start/stop arbitrary system 
threads, then the test may still fail even with the fix, but I should 
say the fix improves the test.

Line 176:
    // assuming no system thread is added
so here at line 177 is still a potential failure, even very little.

To know a thread status, better to call
    Thread.getState()

for example we can save all  MyThread instances into a list, and then 
check them one by one like:
    for (Thread t : list) {
       while (t.getState() != TERMINATED) {
          Thread.sleep(10);
       }
    }
(can add a max waiting time here)

this is because it is possible that a MyThread is suspended after calling:
    barrier.signal();
but before leaving run() method, especially when stopping many threads 
at same time on a slow testing machine.

Shanliang

Jaroslav Bachorik wrote:
> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test
> seems to be failing intermittently.
>
> The test checks the functionality of the
> j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by
> capturing the current value of "getPeakThreadCount()", starting a
> predefined number of the user threads, stopping them and resetting the
> stored peak value and making sure the new peak equals to the number of
> the actually running threads.
>
> The main problem is that it is not possible to prevent JVM to start/stop
> arbitrary system threads while executing the test. This might lead to
> small variations of the reported peak (a short-lived system thread is
> started while the batch of the user threads is running) or the expected
> number of running threads (again, a short-lived system thread is started
> at the moment the test asks for the number of running threads).
>
> The patch does not fix those shortcomings as it is not really possible
> to do given the nature of the JVM threading system. It rather tries to
> relax the conditions while still maintaining the ability to detect
> functional problems - eg. decreasing peak without explicitly resetting
> it and reporting false number of threads.
>
> The webrev is at:
> http://cr.openjdk.java.net/~jbachorik/8020875/webrev.00
>
> Thanks,
>
> -JB-
>