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

David Holmes david.holmes at oracle.com
Tue Jul 23 01:19:39 PDT 2013


Hi Jaroslav,

On 22/07/2013 9:55 PM, 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).

Do you know what "system threads" these are? I would not expect VM 
internal threads to be counted in getPeakThreadCount(), but even if they 
are I can't think of any short-lived threads that get created other than 
the Signal handling thread.

> 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

Seems reasonable.

David
-----

> Thanks,
>
> -JB-
>


More information about the serviceability-dev mailing list