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

Jaroslav Bachorik jaroslav.bachorik at oracle.com
Wed Jul 24 05:02:13 PDT 2013


On 07/24/2013 01:58 PM, David Holmes wrote:
> Aside: it is really annoying that jmx-dev mangles the subject such that
> cross-posts end up creating two different email threads :(
> 
> On 24/07/2013 9:50 PM, 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.
> 
> Correct.
> 
>> 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.
> 
> Yes.
> 
>> 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.
> 
> I'm unclear what the "different paths" are.

Hm, there might be only one "different path" in Java -
Thread.dumpStack() and Thread.getAllStackTraces()

-JB-

> 
> David
> -----
> 
>> -JB-
>>
>>>
>>> David
>>> -----
>>>
>>>> Mandy
>>



More information about the serviceability-dev mailing list