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

[shanliang]

Jaroslav Bachorik wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/24/2013 10:38 AM, shanliang wrote:
>   
>> - ---> MBean.getThreadCount() = 7
>>
>> ................
>>
>> - ---> MBean.getThreadCount() = 6
>>
>> I suppose that you added sleep between 2 calls, then there might be
>> an issue with MBean.getThreadCount()
>>     
>
> Actually I tried it with sleep for 10ms as well as without. It seems
> that the natural latency between those 2 calls is enough to get the
> thread count updated to the actual value.
>   
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.

Shanliang

> - -JB-
>
>   
>> Shanliang
>>
>> Jaroslav Bachorik wrote: On 07/24/2013 09:21 AM, shanliang wrote:
>>
>>     
>>>>> Just to be a test, after terminated 8 threads and checked
>>>>> their states by calling Thread.join() (must be same to 
>>>>> Thread.getState()), DO sleep sometime and then call 
>>>>> mbean.getThreadCount(), if it reports a right number, then we
>>>>> may need to verify mbean.getThreadCount() method.
>>>>>
>>>>>           
>> The result is:
>>
>> Thread: Thread[Signal Dispatcher,9,system] Thread:
>> Thread[Finalizer,8,system] Thread: Thread[worker-12,5,main] Thread:
>> Thread[Reference Handler,10,system] Thread: Thread[main,5,main] 
>> Thread: Thread[worker-13,5,main] ---> MBean.getThreadCount() = 7 
>> Thread(1): Thread[Signal Dispatcher,9,system] Thread(1):
>> Thread[Finalizer,8,system] Thread(1): Thread[worker-12,5,main] 
>> Thread(1): Thread[Reference Handler,10,system] Thread(1):
>> Thread[main,5,main] Thread(1): Thread[worker-13,5,main] --->
>> MBean.getThreadCount() = 6
>>
>> -JB-
>>
>>
>>
>>     
>>>>> Shanliang
>>>>>
>>>>> Jaroslav Bachorik wrote:
>>>>>
>>>>>           
>>>>>> On Wed 24 Jul 2013 08:20:56 AM CEST, Mandy Chung wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> On 7/24/2013 2:09 PM, Daniel Fuchs wrote:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> On 7/24/13 8:01 AM, Mandy Chung wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> I am catching up on this thread....
>>>>>>>>>
>>>>>>>>> The thread count counts Java threads that are not
>>>>>>>>> hidden. I believe all VM internal threads are hidden
>>>>>>>>> from external API. This test runs in othervm mode and
>>>>>>>>> AFAICT the thread count is expected to be
>>>>>>>>> deterministic.  I don't expect the VM will start and
>>>>>>>>> terminate any thread any time.
>>>>>>>>>
>>>>>>>>> I agree with David that we should diagnose why there
>>>>>>>>> is one additional thread started before the reset.
>>>>>>>>> If it is the LogManager$Cleaner thread, like David
>>>>>>>>> said, the VM is shutting down while the test is still
>>>>>>>>> running which doesn't quite make sense.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> I think that Shanliang's suspicion that a thread might
>>>>>>>> be still alive if unscheduled just after having called
>>>>>>>> its barrier.signal() is a very good suggestion. I would
>>>>>>>> advise calling thread.join() on all threads in
>>>>>>>> terminateThreads, just to make sure they are all really
>>>>>>>> dead and not in some comatose state... If Shanliang is
>>>>>>>> right then the test would be failing because some of
>>>>>>>> the threads we think are dead are not actually dead yet
>>>>>>>> - and not because of some new VM thread that nobody can
>>>>>>>> see :-)
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> Thanks for pointing that out.
>>>>>>>
>>>>>>> I agree that the test should be changed to call
>>>>>>> Thread.join(). There may be other java.lang.management
>>>>>>> tests that should also be fixed to call Thread.join.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> I've tried using Thread.join() but I am still getting the
>>>>>> thread count discrepancy.
>>>>>>
>>>>>> Specifically: 1. 10 worker threads have been successfully
>>>>>> started - mben.getThreadCount() reports 14 and 
>>>>>> Thread.getAllStackTraces() returns 14 items --- Thread: 
>>>>>> Thread[Signal Dispatcher,9,system] Thread: 
>>>>>> Thread[worker-5,5,main] Thread: Thread[worker-7,5,main]
>>>>>> Thread: Thread[worker-9,5,main] Thread:
>>>>>> Thread[worker-12,5,main] Thread: Thread[worker-11,5,main]
>>>>>> Thread: Thread[Reference Handler,10,system] Thread:
>>>>>> Thread[main,5,main] Thread: Thread[worker-10,5,main]
>>>>>> Thread: Thread[worker-8,5,main] Thread: 
>>>>>> Thread[Finalizer,8,system] Thread: Thread[worker-6,5,main]
>>>>>> Thread: Thread[worker-13,5,main] Thread:
>>>>>> Thread[worker-4,5,main] --- 2. Terminating 8 threads 3.
>>>>>> After the threads have been terminated (waiting on
>>>>>> Thread.join() for them to die) - mbean.getThreadCount()
>>>>>> reports 7 while Thread.getAllStackTraces() returns only 6
>>>>>> items --- Thread: Thread[Signal Dispatcher,9,system]
>>>>>> Thread: Thread[Finalizer,8,system] Thread: 
>>>>>> Thread[worker-12,5,main] Thread: Thread[Reference 
>>>>>> Handler,10,system] Thread: Thread[main,5,main] Thread: 
>>>>>> Thread[worker-13,5,main] ---
>>>>>>
>>>>>> This would almost point to mbean.getThreadCount() reporting
>>>>>> a stale value. Is that possible?
>>>>>>
>>>>>> -JB-
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Mandy
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>             
>>     
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJR75MOAAoJELSZyqhGiB1M1CgIAKcMQMTZlZqM6qFsI5nCc53Y
> fHEFykf4792Qh/TgqDiyNbDCiTgY0TWoChUEJJEQvlho01TpJmKbkyqx5fNoNqjO
> l94p073f4GsUSHR4exGmDjJkg87DCzhbhX3bZdwjfsxJHxup8qrXxpz4c5lyBHDH
> ttoSasrcDIUh7cRoeqY7uWkIcnc8xI1cj7p3JlPUwB251eKzh15GZgMJhNKrn9N2
> nhjpGywh3t/kwcsDVCibgBBOJ4ju55PRDZTyxH2R6o4fM+Twl80nZSaxUJiPUfEe
> yDNFUxMfPcNH+jRAhRlmKRZtfHfYV/nwaj/eqCL8CDtluzVR+lraII81pg7OU+c=
> =lqyg
> -----END PGP SIGNATURE-----
>