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

Jaroslav Bachorik jaroslav.bachorik at oracle.com
Wed Jul 24 00:35:02 PDT 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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/

iQEcBAEBAgAGBQJR74OmAAoJELSZyqhGiB1M4k8H/2hM5o2vVe2lfhc374IBaR5R
R8i9Z2n0prBRKIqg4bTkAcllq5pmdozxwFyaEBzJtAGh9vnL7Tmojn6ksg9K+MMl
bSgWSeg+gSZyymS7aE8rTVqKigH8vNOpHOogePDrUOCZGeZgJIMpmY1QcVbLeq8k
mkz5mPYxEE2E7gt8cjvcXknOWeQUTyZILWGIPBfx9FL0iwBtK5h0PnfasR7bCxcR
DO48USIuTxe+aN687OkAlJq9bCR6HRzWQiaSdi4ROVyrx2xYtir4n9sZtNWJwokv
3p5TdX6S64jnVZZMjbPJgCENTYMvTeRCj/8GvCYlI9KQEa9x2zhU2wIp5Zw4ag4=
=4vkV
-----END PGP SIGNATURE-----


More information about the serviceability-dev mailing list