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

[shanliang]

Jaroslav Bachorik wrote:
> On 07/24/2013 01:21 PM, David Holmes wrote:
>   
>> On 24/07/2013 7:31 PM, Mandy Chung wrote:
>>     
>>> On 7/24/2013 4:50 PM, shanliang wrote:
>>>       
>>>> So we have 2 kinds of issues here:
>>>> 1) the test related, like Thread state checking, we can fix them in
>>>> the test
>>>> 2) MBean.getThreadCount() issue, we can create a bug to trace it (add
>>>> your test case to the bug), and add a workaround (sleep or call 2
>>>> times) in the test to make the test pass. Mandy is the expert and
>>>> better to get her opinion.
>>>>         
>>> It's probably a race in the VM implementation in determining the thread
>>> count.   You will need to diagnose the VM implementation and compare the
>>> thread list and the implementation of getting the thread count (check
>>> hotspot/src/share/vm/services/threadService.cpp)
>>>       
>> There is a considerable code path between the point where a terminating
>> thread causes Thread.join() to be allowed to return, and the point where
>> the live thread count gets decremented. So using join() does not help
>> here. Arguably JVMTI should have based its counts around the lifecycle
>> of the Java thread not the underlying native thread.
>>     
>
> So, if I understand it correctly, it is not possible to get 100%
> accuracy of the thread related counters in situations when you create
> and terminate a number of threads rapidly.
>   
If Thread.getAllStackTraces() could get right number, then we could not 
say "it is not possible"?  :)

Shanliang
> In that case this test could be fixed with a small waiting period after
> all the joined threads were terminated - just to make sure that all the
> exiting threads were properly collected.
>
> The only question remains whether a bug should be filed for the
> discrepancy between the thread counters obtained from ThreadMXBean and
> the ones coming from different paths.
>
> -JB-
>
>   
>> David
>> -----
>>
>>     
>>> Mandy
>>>       
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130724/3fb1fe77/attachment-0001.html