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