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

[Jaroslav Bachorik]

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

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