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

[Jaroslav Bachorik]

On 07/23/2013 10:19 AM, David Holmes wrote:
> 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.

Unfortunatelly I don't. Capturing the thread dump at the moment of
discovering the discrepancy seems to to be too late. I tried monitoring
the JVM under the test from external tools but it just brings more
entropy to the result.

I am completely relying on the JVM native thread accounting to be
correct and accurate - that it reports the thread count peak based on
the real data.

-JB-

> 
>> 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-
>>